NPS 

mlSTANTIAPERSCffN77A/V| 


NAVAL 

POSTGRADUATE 

SCHOOL 

MONTEREY,  CALIFORNIA 


THESIS 


BUILDING  A  LOCAL  SPACE  SITUATIONAL 
AWARENESS  (SSA)  ARCHITECTURE  USING  HOSTED 

PAYLOADS 

by 

Farakh  B.  Zaman 
September  2013 

Thesis  Advisor:  Douglas  H.  Nelson 

Second  Reader:  Mark  Rhoades 


Approved  for  public  release;  distribution  is  unlimited 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


REPORT  DOCUMENTATION  PAGE  |  Form  Appmved  OMB  No  0704-0188 

Public  reporting  burden  for  this  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instruction, 
searching  existing  data  sources,  gathering  and  maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send 
comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information,  including  suggestions  for  reducing  this  burden,  to 
Washington  headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington,  VA 
22202^1302,  and  to  the  Office  of  Management  and  Budget,  Paperwork  Reduction  Project  (0704-0188)  Washington,  DC  20503. 

I.  AGENCY  USE  ONLY  (Leave  blank)  2.  REPORT  DATE  3.  REPORT  TYPE  AND  DATES  COVERED 

September  2013  Master’s  Thesis 

4.  TITLE  AND  SUBTITLE  5.  FUNDING  NUMBERS  — — 

BUILDING  A  LOCAL  SPACE  SITUATIONAL  AWARENESS  (SSA) 

ARCHITECTURE  USING  HOSTED  PAYLOADS _ 

6.  AUTHOR(S) 

7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES)  8.  PERFORMING  ORGANIZATION 

Naval  Postgraduate  School  REPORT  NUMBER 

Monterey,  CA  93943-5000 

9.  SPONSORING  /MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES)  10.  SPONSORING/MONITORING 
N/A  AGENCY  REPORT  NUMBER 

II.  SUPPLEMENTARY  NOTES  The  views  expressed  in  this  thesis  are  those  of  the  author  and  do  not  reflect  the  official  policy 

or  position  of  the  Department  of  Defense  or  the  U.S.  Government.  IRB  Protocol  number _ N/A _ . 

12a.  DISTRIBUTION  /  AVAILABILITY  STATEMENT  12b.  DISTRIBUTION  CODE  ~ 

Approved  for  public  release;  distribution  is  unlimited  A 

13.  ABSTRACT  (maximum  200  words) 

From  a  military  standpoint,  space-based  capabilities  and  the  need  to  know  what  is  happening  in  space,  or  Space 
Situational  Awareness  (SSA),  have  become  invaluable.  Current  SSA  capabilities  are  expensive  and  are  limited  in 
scope.  Hosted  payloads  however,  provide  a  unique  method  to  provide  SSA  in  a  relatively  inexpensive  manner.  This 
thesis  explores  the  development  of  an  architecture  for  SSA  using  hosted  payloads. 

For  this  thesis,  research  was  conducted  on  existing  systems.  NASA  and  Air  Force  programs  were  reviewed  to  gain  an 
understanding  of  hosted  payloads,  and  a  set  of  generic  high-level  requirements  were  developed  for  a  hosted  payload. 
These  requirements  will  meet  the  needs  of  a  hosted  SSA  payload  that  can  enable  a  larger  SSA  architecture  using 
hosted  payloads.  Once  the  requirements  were  developed,  modeling  and  simulation  using  Satellite  Tool  Kit  (STK)  was 
were  employed  to  develop  an  optimal  SSA  system  using  hosted  payloads.  Finally,  once  the  architecture  was  defined, 
an  Operational  View  -  1  (OV-1)  was  developed  to  provide  a  graphical  representation  of  the  architecture. 


14.  SUBJECT  TERMS  Hosted  Payloads,  Space  Situational  Awareness,  SSA,  Space  15.  NUMBER  OF 

PAGES 

_ 133 

16.  PRICE  CODE 


17.  SECURITY 

18.  SECURITY 

19.  SECURITY 

20.  LIMITATION  OF 

CLASSIFICATION  OF 

CLASSIFICATION  OF  THIS 

CLASSIFICATION  OF 

ABSTRACT 

REPORT 

PAGE 

ABSTRACT 

Unclassified 

Unclassified 

Unclassified 

UU 

NSN  7540-01-280-5500  Standard  Form  298  (Rev.  2-89) 

Prescribed  by  ANSI  Std.  239-18 


1 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


11 


Approved  for  public  release;  distribution  is  unlimited 


BUILDING  A  LOCAL  SPACE  SITUATIONAL  AWARENESS  (SSA) 
ARCHITECTURE  USING  HOSTED  PAYLOADS 


Farakh  B.  Zaman 
Captain,  United  States  Air  Force 
B.S.,  University  of  Missouri,  Kansas  City,  2005 


Submitted  in  partial  fulfillment  of  the 
requirements  for  the  degree  of 


MASTER  OF  SCIENCE  IN  SYSTEMS  ENGINEERING 


from  the 


NAVAL  POSTGRADUATE  SCHOOL 
September  2013 


Author;  Farakh  B.  Zaman 


Approved  by:  Douglas  H.  Nelson 

Thesis  Advisor 


Mark  Rhoades 
Second  Reader 


Clifford  A.  Whitcomb 

Chair,  Department  of  Systems  Engineering 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


IV 


ABSTRACT 


From  a  military  standpoint,  space-based  capabilities  and  the  need  to  know  what  is 
happening  in  space,  or  Space  Situational  Awareness  (SSA),  have  become  invaluable. 
Current  SSA  capabilities  are  expensive  and  are  limited  in  scope.  Hosted  payloads 
however,  provide  a  unique  method  to  provide  SSA  in  a  relatively  inexpensive  manner. 
This  thesis  explores  the  development  of  an  architecture  for  SSA  using  hosted  payloads. 

For  this  thesis,  research  was  conducted  on  existing  systems.  NASA  and  Air  Force 
programs  were  reviewed  to  gain  an  understanding  of  hosted  payloads,  and  a  set  of 
generic  high-level  requirements  were  developed  for  a  hosted  payload.  These 
requirements  will  meet  the  needs  of  a  hosted  SSA  payload  that  can  enable  a  larger  SSA 
architecture  using  hosted  payloads.  Once  the  requirements  were  developed,  modeling  and 
simulation  using  Satellite  Tool  Kit  (STK)  was  were  employed  to  develop  an  optimal  SSA 
system  using  hosted  payloads.  Finally,  once  the  architecture  was  defined,  an  Operational 
View  -  1  (OV-1)  was  developed  to  provide  a  graphical  representation  of  the  architecture. 


v 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


vi 


TABLE  OF  CONTENTS 


I.  OVERVIEW . 1 

A.  INTRODUCTION . 1 

B.  BACKGROUND . 3 

C.  PURPOSE  OF  STUDY:  NEED  FOR  SSA . 8 

D.  RESEARCH  QUESTIONS . 10 

E.  BENEFITS  OF  STUDY . 1 1 

F.  SCOPE  AND  METHODOLOGY . 1 1 

1.  Scope . 11 

2.  Methodology . 11 

II.  SYSTEMS  ENGINEERING  METHODOLOGY . 13 

A.  INTRODUCTION . 13 

B.  GENERAL  SYSTEMS  ENGINEERING . 13 

C.  SPACE  SYSTEMS  ENGINEERING . 16 

III.  PROBLEM  DEFINITION . 19 

A.  CURRENT  CAPABILITIES . 19 

B.  STAKEHOLDER  ANALYSIS . 26 

C.  FUNCTIONAL  ANALYSIS . 29 

D.  REQUIREMENTS  ANALYSIS . 31 

IV.  SYSTEMS  ARCHITECTURE  DESIGN . 37 

A.  ARCHITECTURAL  DEVELOPMENT  OVERVIEW . 37 

B.  STK  ANALYSIS . 38 

C.  ARCHITECTURE  CONCLUSIONS . 97 

V.  CONCLUSIONS . 101 

A.  RESEARCH  SUMMARY . 101 

B.  AREAS  FOR  FURTHER  RESEARCH . 102 

INITIAL  DISTRIBUTION  LIST . 109 


vii 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


LIST  OF  FIGURES 


Figure  1 .  Orbit  Types  (From  Chatters  IV,  Eberhardt  and  Warner  2009,  90) . 4 

Figure  2.  Satellite  Tool  Kit  (STK)  Depiction  of  Space  Objects  in  LEO  (From 

Johnson  and  Zaman  2012) . 6 

Figure  3.  Artist  Rendering  of  LEO  Space  Objects  (From  Johnson  and  Zaman  2012) . 6 

Figure  4.  U.S.  Space  Surveillance  Network  (From  Johnson  and  Zaman  2012) . 19 

Figure  5.  Wide  Area  Augmentation  System  (From  Federal  Aviation  Adminstration 

2010) . 21 

Figure  6.  WAAS  Footprint  (From  Federal  Aviation  Adminstration  2010) . 22 

Figure  7.  IRIS  Payload  (From  INTELSAT  General  Corporation  2013) . 23 

Figure  8.  Functional  Decomposition . 30 

Figure  9.  Selection  of  LEO  Orbit  in  STK . 40 

Figure  10.  Remove  Star  Background  in  STK . 41 

Figure  1 1 .  Creation  of  Chain  in  STK . 42 

Figure  12.  Define  Coverage  Area . 43 

Figure  13.  Assign  Sensor . 44 

Figure  14.  Define  Figure  of  Merit  (FOM) . 45 

Figure  15.  Run  Coverage . 46 

Figure  16.  Legend . 47 

Figure  17.  Completed  Coverage . 48 

Figure  18.  Analyzer  Setup . 49 

Figure  19.  Select  Parametric  Study  Tool . 50 

Figure  20.  Parametric  Study  Tool  Menu . 5 1 

Figure  2 1 .  Set  Broad  Range  for  Inclination . 52 

Figure  22.  Example  Plot . 53 

Figure  23.  Output  for  Optimal  Inclination . 54 

Figure  24.  Set  Broad  Range  for  RAAN . 55 

Figure  25.  Optimal  Output  for  RAAN . 56 

Figure  26.  Semi-major  vs.  Semi-minor  Axis . 57 

Figure  27.  Set  Broad  Range  for  Semi-major  Axis . 58 

Figure  28.  Output  of  Broad  Range  for  Semi-major  Axis . 59 

Figure  29.  Small  vs.  Large  Detector  Pitch . 60 

Figure  30.  Cone  Angle . 60 

Figure  3 1 .  Passive  Earth  Values  Held  Steady . 61 

Figure  32.  Output  of  Semi-Major  Axis  with  Nadir  Sensor  Constrained  to  5m 

Resolution,  100m  Focal  Length . 62 

Figure  33.  Output  of  Semi-Major  Axis  with  Nadir  Sensor  Constrained  to  5m 

Resolution,  50m  Focal  Length . 63 

Figure  34.  Output  of  Semi-Major  Axis  with  Nadir  Sensor  Constrained  to  5m 

Resolution,  25m  Focal  Length . 64 

Figure  35.  Output  of  Semi-Major  Axis  with  Nadir  Sensor  Constrained  to  5*10-6m 

Pixel  Pitch  and  10m  Focal  Length . 65 


IX 


Figure  36.  Output  of  Semi-Major  Axis  with  Nadir  Sensor  Constrained  to  5*10-7m 

Pixel  Pitch  and  lm  Focal  Length . 66 

Figure  37.  Output  of  Semi-Major  Axis  with  Nadir  Sensor  Constrained  to  5*10-7m 

Pixel  Pitch,  lm  Focal  Length  and  lm  Resolution . 67 

Figure  38.  Output  for  Semi-major  Axis,  Constrained  to  lm  Resolution,  0.5m  Focal 

Length,  5*10-7m  Pixel  Pitch . 68 

Figure  39.  Output  for  Semi-major  Axis,  No  Resolution  Constraint,  0.5m  Focal 

Length,  5*  10- 7m  Pixel  Pitch . 69 

Figure  40.  3-Dimensional  Plot  of  2-Dimensional  Parametric  Study  for  Inclination  vs. 

Semi-major  Axis  with  No  Resolution  Constraint,  5*10-7m  Pixel  Pitch  and 

lm  Focal  Length . 70 

Figure  41.  3-Dimensional  Plot  of  2-Dimensional  Parametric  Study  for  Inclination  vs. 

Semi-major  Axis  with  lm  Resolution  Constraint,  5*10-7m  Pixel  Pitch  and 

lm  Focal  Length . 71 

Figure  42.  3-Dimensional  Plot  of  2-Dimensional  Parametric  Study  for  Inclination  vs. 

Semi-major  Axis  with  lm  Resolution  Constraint,  5*  10 -7m  Pixel  Pitch, 

lm  Focal  Length  and  Vertex  Centered . 72 

Figure  43.  3-Dimensional  Plot  of  2-Dimensional  Parametric  Study  for  Inclination  vs. 

Semi-major  Axis  with  lm  Resolution  Constraint,  5*  10 -7m  Pixel  Pitch, 

lm  Focal  Length,  Vertex  Centered  and  X-axis  Lower  Bound  Set  to  120° . 73 

Figure  44.  Contour  of  2-Dimensional  Parametric  Study  for  Inclination  vs.  Semi¬ 
major  Axis  with  lm  Resolution  Constraint,  5*  10 -7m  Pixel  Pitch,  lm 

Focal  Length,  Vertex  Centered  and  X-axis  Lower  Bound  Set  to  120° . 74 

Figure  45.  Parametric  Study  Menu  for  Optimal  Pixel  Size . 75 

Figure  46.  Optimal  Pixel  Pitch  Plot . 76 

Figure  47.  Bar  Graph  for  Optimal  Pixel  Pitch . 77 

Figure  48.  Parametric  Study  Menu  for  Optimal  Focal  Length . 78 

Figure  49.  Optimal  Focal  Length  Plot . 79 

Figure  50.  3-Dimensional  Plot  of  2-Dimensional  Parametric  Study  for  Pixel  Pitch  vs. 

Focal  Length . 80 

Figure  5 1 .  Contour  Plot  for  Focal  Length  vs.  Pixel  Pitch . 81 

Figure  52.  Setup  of  Design  Explorer  Surrogate  Optimization  Tool . 82 

Figure  53.  SEQOPT  Tool  Output  1 . 83 

Figure  54.  SEQOPT  Tool  Output  2 . 83 

Figure  55.  Select  EOIR  Sensor  Plug-In . 84 

Figure  56.  Sensor  Properties  #  1 . 85 

Figure  57.  Sensor  Properties  #  2 . 86 

Figure  58.  Sensor  Properties  #3 . 87 

Figure  59.  Sensor  Properties  #  4 . 88 

Figure  60.  Forward  and  Aft  SSA  Sensors . 89 

Figure  6 1 .  Debris  Parameter  Set-up  in  EOIR  Toolkit . 90 

Figure  62.  Space  Debris  in  Orbital  Plane . 91 

Figure  63.  Sensor  Debris  and  Star  View  #1 . 92 

Figure  64.  Sensor  Debris  and  Star  View  #  2 . 93 


x 


Figure  65.  Sensor  Debris  and  Star  View  #3 . 93 

Figure  66.  EOIR  Sensor- to-Target  Metric  Report  Generation . 94 

Figure  67.  SNR  for  Space  Debris  30°  Away . 95 

Figure  68.  Single  Plane  Hosted  SSA  Payload  Constellation . 96 

Figure  69.  Single  Plane  Hosted  SSA  Payload  Constellation  with  GEO  Relay  and 

Downlink  to  Monterey,  CA . 97 

Figure  70.  Proposed  Operational  View . 98 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


LIST  OF  TABLES 


Table  1 .  List  of  Stakeholders . 26 

Table  2.  Generic  Hosted  Payload  Requirements . 32 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


xiv 


LIST  OF  ACRONYMS  AND  ABBREVIATIONS 


AFOTEC 

Air  Force  Test  and  Evaluation  Center 

AFSPC 

Air  Force  Space  Command 

ASAT 

Anti-satellite 

C2 

Command  and  Control 

CDR 

Critical  Design  Review 

CHIRP 

Commercially  Hosted  Infrared  Payload 

CIU 

Common  Interface  Unit 

DoD 

Department  of  Defense 

DoDAF 

Department  of  Defense  Architecture  Framework 

EMP 

Electro-magnetic  Pulse 

EOIR 

Electro-optical  and  Infrared 

FAA 

Federal  Aviation  Administration 

FOM 

Figure  of  Merit 

FOV 

Field  of  View 

GBAS 

Ground  Based  Augmentation  System 

GEO 

Geostationary  Earth  Orbit 

GIG 

Global  Infonnation  Grid 

GOLD 

Global-scale  Observations  of  the  Limb  and  Disk 

GPS 

Global  Positioning  System 

HEO 

Highly  Elliptical  Orbit 

IMINT 

Imagery  Intelligence 

IR 

Infrared 

XV 


IRIS 

Internet  Routing  In  Space 

ISS 

International  Space  Station 

JSpOC 

Joint  Space  Operations  Center 

Km 

Kilometer 

LEO 

Low  Earth  Orbit 

LWR 

Laser  Warning  Receiver 

m 

meter 

MEO 

Medium  Earth  Orbit 

MISTI 

Multispectral  Imaging  System  for  the  Thermosphere  and 
Ionosphere 

NASA 

National  Aeronautics  and  Space  Administration 

NRO 

National  Reconnaissance  Office 

OPCOM 

Operational  Command 

OV 

Operational  View 

OV-1 

Operational  View-1 

PM 

Program  Manager 

RAAN 

Right  Ascension  of  the  Ascending  Node 

RF 

Radio  Frequency 

RWR 

Radio  Warning  Receiver 

SASSA 

Self  Aware  Space  Situational  Awareness 

SSN 

Space  Surveillance  Network 

STK 

Satellite  Tool  Kit 

SWAP 

Size,  Weight  and  Power 

TACOM 

Tactical  Command 

XVI 


TIGRIS 


Thermosphere  Ionosphere  Global  and  Regional  Imaging  System 
TRD  Technical  Requirements  Document 

TRL  Technology  Readiness  Level 

USAF  United  States  Air  Force 

USCG  United  States  Coast  Guard 

WAAS  Wide  Area  Augmentation  System 


XVII 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


EXECUTIVE  SUMMARY 


From  a  military  standpoint,  space-based  capabilities  and  the  need  to  know  what  is 
happening  in  space,  or  Space  Situational  Awareness  (SSA),  have  become  invaluable. 
Current  SSA  capabilities  are  expensive  and  are  limited  in  capabilities.  This  researcher 
was  motivated  by  the  possibilities  that  hosted  payloads  could  provide  for  SSA.  Hosted 
payloads  are  small  payloads  attached  to  larger  satellites  that  typically  perform  missions 
independently  of  the  host  spacecraft.  Hosted  payloads  afford  a  unique  method  to  provide 
SSA  in  a  relatively  inexpensive  manner.  With  this  in  mind,  this  thesis  explored  the 
development  of  architecture  for  SSA  using  hosted  payloads. 

For  this  thesis,  research  was  conducted  on  existing  systems.  Air  Force  and  NASA 
programs  were  reviewed  to  gain  an  understanding  of  hosted  payloads.  What  was  found 
was  a  sporadic  use  of  hosted  payloads  to  accomplish  various  missions.  There  are  various 
government  agencies  that  use  hosted  payloads  for  applications  such  as  remote  sensing, 
navigation  and  scientific  applications.  However,  the  use  of  hosted  payloads  with  respect 
to  SSA  was  limited.  Additionally,  there  is  no  single  standard  for  hosted  payloads  to  be 
built  to.  Instead  hosted  payloads  are  custom  made  for  each  particular  application.  Instead 
of  having  custom-built  payloads  for  every  mission,  a  foundation  to  build  hosted  payloads 
for  SSA  missions  was  developed  in  the  form  of  high-level  requirements.  The  nine 
requirements  laid  out  in  Table  2  of  this  thesis  build  the  foundation  for  hosted  payloads  to 
be  used  for  SSA  missions.  Once  the  requirements  were  developed,  modeling  and 
simulation  using  Satellite  Tool  Kit  (STK)  was  employed  to  develop  a  notional  SSA 
system  using  hosted  payloads. 

The  STK  modeling  was  done  to  show  the  capabilities  of  a  SSA  system. 
Stakeholder  analysis  was  employed  to  make  assumptions  about  what  a  notional  SSA 
system  using  hosted  payloads  limited  to  a  single  plane  should  consist  of.  The  resulting 
system  was  a  three-sensor  hosted  payload  SSA  system.  The  first  sensor  was  a  nadir 
facing  (e.g.,  Earth  facing)  optical  sensor  for  detecting  ground-based  threats.  The  other 
two  sensors  faced  forward  and  aft  to  detect  threats  along  the  orbital  path.  The  various 
parameters  for  the  optical  sensors  such  as  detector  pitch  (e.g.,  pixel  size),  focal  length  and 


cone  angle  were  optimized  to  provide  the  maximum  amount  of  SSA  coverage  possible  in 
24  hours.  For  the  nadir  sensor,  this  meant  greater  number  of  revisits  over  a  single  point 
on  earth  in  a  24-hour  period.  Additionally,  the  orbit  for  the  notional  system  was  also 
optimized  to  find  the  best  inclination,  semi-major  axis  and  right  ascension  of  the 
ascending  node  (RAAN).  Finally,  once  the  notional  system  was  fully  modeled  in  STK,  an 
architecture  was  defined  in  an  Operational  View  -  1  (OV-1)  to  provide  a  graphical 
representation  of  the  architecture. 

There  are  areas  for  further  research  before  the  concepts  in  this  thesis  could  be 
made  into  an  operational  system.  However,  the  research  and  analysis  conducted  in  this 
thesis  provides  a  sound  starting  point  for  making  a  SSA  system  using  hosted  payloads. 
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I.  OVERVIEW 


A.  INTRODUCTION 

“Well  our  object  collision  budget’s  a  million  dollars,”  says  NASA  Project  Director 
Dan  Truman  in  Armageddon.  “That  allows  us  to  track  about  3%  of  the  sky,  and  begging  your 
pardon  sir,  but  it’s  a  big-ass  sky.”  While  this  quote  by  Truman’s  character  in  the  1998  movie 
isn’t  exactly  true,  as  the  United  States  space  surveillance  budget  for  2012  is  approximately 
$400  million  dollars,  the  sentiment  expressed  by  him  is  (Butler  2013,  1).  Space  is  a  vast 
expanse  and  the  ability  for  mankind  to  track  objects  in  space  is  limited.  Even  in  the  areas 
close  to  Earth,  the  ability  of  the  United  States  to  track  objects  is  not  as  great  as  one  may  think 
(Weeden  2009,  2).  In  the  United  States  Air  Force,  the  ability  to  track  objects  in  space  is 
commonly  referred  as  space  situational  awareness  (SSA). 

SSA  today  is  more  important  than  ever  due  to  the  fact  that  more  nations  are 
gaining  the  capability  to  place  objects  in  space  (United  States  Air  Force  2004,  1).  From 
the  middle  of  the  20th  century  to  today,  the  use  of  space  has  gone  from  being  the  object 
of  science  fiction,  to  being  entwined  in  the  daily  lives  of  human  beings.  While  some  may 
not  realize,  the  technology  used  in  space  today  touches  most  people’s  daily  lives  in 
significant  ways.  For  example,  when  a  purchase  is  made  at  a  gas  station,  a  Global 
Positioning  System  (GPS)  satellite  is  involved  in  time  stamping  the  transaction 
(Stromberg  2013).  Our  smart  phones  and  mapping  sites  such  as  Google  Maps  use 
imagery  collected  by  satellites  (Richelson  2008,  175).  People  use  GPS  navigation 
systems  to  know  where  they  are  in  the  world.  Airplanes  use  satellite  communication  to 
receive  messages  from  control  towers.  These  are  just  a  few  examples  of  how  space 
technology  has  become  part  of  the  daily  lives  of  average  citizens. 

From  a  military  standpoint,  space-based  capabilities  and  the  need  to  know  what  is 
happening  in  space,  or  SSA,  has  become  invaluable  as  well  (United  States  Air  Force 
2001,  1). 

Just  as  the  advent  of  airpower  greatly  enhanced  military  operations  of  the 
time,  space  forces,  likewise,  greatly  enhance  modern  military  operations 
across  the  spectrum  of  conflict.  Space  assets  have  not  only  added  to  our 
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defense  capabilities  but  have  also  changed  the  way  our  military  does 
business.  Air  Force  doctrine  views  air,  space,  and  information  as  key 
ingredients  for  dominating  the  battlespace  and  ensuring  superiority 
(United  States  Air  Force  2001,  1). 

Protecting  U.S.  space-based  capabilities  requires  SSA.  While  the  current  system 
of  SSA  sensors  provides  data  required  to  maintain  a  catalog  of  space  objects,  the 
capability  is  limited  (Weeden  2009,  1).  Objects  of  a  certain  size  or  in  certain  locations  in 
space  cannot  be  accurately  identified  and  tracked  in  a  timely  manner  (Weeden  2009,  2). 
At  times  even  the  objects  that  can  be  tracked  have  errors  in  their  position  data.  For 
example,  in  February  2009,  the  accidental  collision  between  two  satellites  took  place 
(Weeden  2009). 

The  facts  known  about  this  collision  are  as  follows.  On  February  10  at 
1156  EST,  Iridium  lost  contact  with  one  of  its  satellites,  Iridium  33.  They 
contacted  the  Joint  Space  Operations  Center  (JSpOC)  at  Vandenberg 
requesting  help  with  resolving  the  anomaly.  Using  their  network  of  radars, 
the  JSpOC  confirmed  that  there  were  two  breakups,  one  corresponding  to 
the  inclination  of  Iridium  33  and  another  in  a  different  inclination,  later 
discovered  to  be  that  of  Cosmos  225 1  (Weeden  2009,  2). 

The  U.S.  space  surveillance  network  (SSN)  was  tracking  these  two  objects,  and  yet  they  still 
collided  (Weeden  2009,  2).  This  is  just  one  example  of  a  collision  in  space.  There  are  other 
instances  of  space  collisions  (Weeden  2009,  3).  In  addition  to  having  to  worry  about 
accidental  collisions  between  spacecraft  and  debris,  there  are  other  dangers  in  space  as  well. 
Small  debris,  such  as  the  thousands  of  pieces  created  by  the  Chinese  antisatellite  test  in  2007, 
can  pose  significant  risk  to  orbiting  spacecraft  (Weeden  2009,  4). 

Some  may  ask  why  additional  sensors  are  not  placed  around  the  world  to  track 
objects.  The  main  reason  is  cost.  Placing  sensors  around  the  world  is  expensive,  on  the 
order  of  hundreds  of  millions  of  dollars  (Pearson,  Levin  and  Oldson  2008,  2).  There  is 
also  a  single  system  in  space,  which  provides  SSA,  the  Space  Based  Space  Surveillance 
Satellite  (SBSS):  however,  this  too  is  extremely  expensive  (Pearson,  Levin  and  Oldson 
2008,  2).  The  SBSS  satellite  launched  by  the  USAF’s  Air  Force  Space  Command 
(AFSPC)  in  2010,  cost  more  than  $1  billion  (Pearson,  Levin  and  Oldson  2008,  2).  So 
how  does  the  U.S.  get  the  SSA  it  needs  while  staying  within  financial  realities?  In  this 
thesis,  a  method  of  changing  the  paradigm  of  how  the  U.S.  conducts  SSA  collection  is 
examined. 
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While  there  will  be  a  continued  need  for  ground-based  radars,  as  well  as  large 
space-based  sensors  such  as  SBSS,  a  paradigm  shift  is  needed  regarding  the  collection  of 
SSA.  Adopting  the  concept  of  “local”  SSA,  and  building  architecture  to  accomplish  this 
would  better  serve  the  SSA  community.  “Local”  SSA  expands  the  traditional  definition 
of  SSA  to  encompass  an  understanding  of  the  immediate  natural  and  manmade 
environment  of  the  satellite.  The  way  to  achieve  “local”  SSA  is  by  adding  small  payloads 
to  larger  satellites.  The  only  mission  of  these  small  payloads  would  be  to  provide  SSA. 
By  adding  these  hosted  payloads  to  larger  space  missions,  multiple  insights  would  be 
enabled.  These  insights  include: 

•  Baseline  trending  to  support  anomaly  identification  and  resolution 

•  Catastrophic  failure  investigation 

•  Threat  detection 

•  Targeting  detection 

•  Collision  avoidance  and  failure  attribution 

Additionally,  protection  measures  could  potentially  be  enabled  to  ensure  space 
asset  availability;  these  protection  measures  would  function  similar  to  flares  on  an  aircraft 
(Johnson  and  Zaman  2012,  1). 

Finally,  moving  forward  with  a  combination  of  traditional  SSA  and  “local”  SSA 
capabilities  would  allow  a  potential  “global”  SSA  picture  to  be  developed  (Johnson  and 
Zaman  2012,  1).  By  utilizing  this  combination  of  hosted  payloads,  as  well  as  traditional 
methods  for  SSA,  robust  SSA  can  be  achieved,  mainly  through  data  fusion  and 
exploitation  (Johnson  and  Zaman  2012,  2).  The  goal  of  this  paper  is  to  examine  how  a 
local  SSA  architecture  can  be  achieved  using  hosted  payloads. 

B.  BACKGROUND 

Knowledge  of  basic  tenninology  and  principles  related  to  space  is  essential  for  a 
full  understanding  of  the  discussion  in  this  thesis.  In  addition,  an  understanding  of  how 
the  U.S.,  and  in  particular  the  USAF,  conducts  space  operations  is  also  important. 

Humans  have  utilized  various  areas  of  space  around  the  Earth  for  different 
purposes.  These  areas  of  space  are  commonly  referred  to  as  orbits.  The  primary  orbits  for 
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satellites  are  low  Earth  orbit  (LEO),  medium  Earth  orbit  (MEO),  geosynchronous  Earth 
orbit  (GEO)  and  highly  elliptical  orbit  (HEO)  (Chatters  IV,  Eberhardt  and  Warner  2009, 
89).  Figure  1  from  Chatters  IV,  Eberhardt  and  Warner  (2009)  below  shows  the  various 
orbits  and  the  missions  associated  with  each  orbital  regime. 


Orbit  Type 

Mission 

Altitude 

Period 

TUP 

Shape 

LEO 

•  Polar  sun-synchronous 

Remote  sensing/ 
weather 

-150-900  km 

-98-104 

min 

-98° 

circular 

•  Inclined  nonpolar 

International  Space 
Station 

-340  km 

-91  min 

-51.6° 

circular 

•  Polar  non-sun-synchronous 

Earth  observing, 
scientific 

-450-600  km 

-90-101 

min 

-80-94° 

circular 

MEO 

•  Semisynchronous 

Navigation, 
communications, 
space  environment 

-20,100  km 

-12  hours 

-55° 

circular 

GEO 

•  Geosynchronous 

•  Geostationary 

Communication, 
early  warning, 
nuclear  detection, 
weather 

-35,786  km 

-24  hours 
(23h  56m 
04s) 

-0° 

circular 

HEO 

•  Molniya 

Communications 

Varies  from 
-495  km  to 
-39,587  km 

-12  hours 
(1 1  h  58m) 

63.4° 

long 

ellipse 

"Orbits  roughly  stay  In  the  same  plane.  This  Indicates  the  tilt  or  Inclination  of  this  plane  relative  to  the  equator.  Near  zero  Is  along  the  equator, 
and  near  90°  is  over  the  poles.  Greater  than  90°  indicates  against  the  rotation  of  the  earth. 


Figure  1.  Orbit  Types  (From  Chatters  IV,  Eberhardt  and  Warner  2009,  90) 

LEO  satellites  orbit  the  Earth  at  an  altitude  between  approximately  100  and  1,000 
statute  miles  (160  to  1,600  km).  At  this  altitude,  the  time  a  satellite  takes  to  orbit  the  earth 
is  about  100  minutes.  This  orbit  time  is  also  known  as  a  period  (Chatters  IV,  Eberhardt 
and  Warner  2009,  89). 

The  inclination  of  an  orbit  is  equal  to  the  maximum  latitude  the  satellite  reaches. 
The  tenn  inclined  nonpolar  orbit  in  Figure  1  refers  to  all  LEO  satellites  that  are  not  in 
near  polar  orbits.  These  types  of  orbits  are  used  when  the  need  to  see  every  point  on  the 
earth  (e.g.,  global  coverage  of  the  earth)  is  not  necessary,  as  in  the  case  of  the 
International  Space  Station.  A  polar  non-sun-synchronous  orbit  is  similar  to  an  inclined 
polar  orbit  except  that  the  inclination  is  nearly  polar  (e.g.,  slightly  less  than  90° 
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inclination).  This  type  of  orbit  is  used  to  maximize  the  coverage  of  the  earth — every 
latitude  will  ultimately  be  passed  over,  and  because  of  the  fast  period,  a  large  part  of  the 
earth’s  surface  will  be  seen  each  day  [10].  This  type  of  orbit  is  commonly  used  by 
communication,  signals  intelligence  (SIGINT)  and  imagery  intelligence  (IMINT) 
satellites  due  to  the  fact  that  the  Earth’s  entire  surface  will  ultimately  be  overflown  [101 
[5],  Since  the  analysis  and  discussion  in  this  thesis  focuses  solely  on  satellites  in  LEO 
orbit,  MEO,  GEO  and  HEO  orbits  will  not  be  discussed  further. 

How  a  satellite  travels  in  space  is  based  on  certain  laws  of  physics.  “Modern  orbit 
types  have  been  developed  based  on  theories  dating  back  centuries”  [101.  There  are  two 
primary  sets  of  laws  that  apply  to  motion  in  space  [111.  Kepler’s  Laws  of  Planetary 
Motion  are  three  laws  that  describe  the  orbit  of  planets  around  the  sun  and  Newton’s 
Laws  of  Motion,  which  describe  the  forces  behind  Kepler’s  laws  [101.  Anything  that  is  in 
space  and  orbiting  some  object  will  follow  the  principles  laid  out  by  these  two  sets  of 
laws,  and  this  applies  to  satellites,  debris  and  natural  objects  [111.  While  these  principles 
will  not  be  discussed  in  detail  in  this  thesis,  it  is  important  for  one  to  understand  that 
motion  in  space  follows  a  consistent  set  of  rules.  Debris  as  well  as  active  space  objects  all 
will  continue  to  move  in  their  orbits  and  at  times,  there  will  be  a  collision  if  SSA  is  not 
available  or  accurate  to  facilitate  and  guide  avoidance  maneuvers. 

As  nations  have  progressed  in  their  technological  advancement,  the  LEO  orbit  has 
become  extremely  crowded  [8].  Debris  creating  Events  such  as  the  Chinese  AS  AT  test  of 
2007  and  the  accidental  collision  of  Iridium  33  and  and  Cosmos  2251  have  made  the 
orbit  even  more  crowded  [2],  The  graphical  depictions  below  from  Johnson  and  Zaman 
(2012)  show  just  how  crowded  the  LEO  orbit  has  become  in  Figure  2  and  Figure  3. 
Objects  represented  in  the  figures  are  those  that  are  greater  than  the  size  of  a  softball.  In 
Figure  2,  the  colors  represent  various  densities  of  objects  in  a  particular  area,  with  green 
being  the  greatest  density  of  objects  and  red  being  the  least. 
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Figure  2.  Satellite  Tool  Kit  (STK)  Depiction  of  Space  Objects  in  LEO  (From 

Johnson  and  Zaman  2012) 


Figure  3. 


Artist  Rendering  of  LEO  Space  Objects  (From  Johnson  and  Zaman  2012) 
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Satellite  systems  are  complex  systems  composed  of  many  different  parts.  While 
this  discussion  will  primarily  focus  on  the  space  segment  of  satellite  systems,  it  should  be 
understood  that  there  are  other  parts  as  well. 

A  satellite  system  is  typically  made  up  of  one  or  more  satellites  (or  space 
vehicles),  terrestrial  satellite  control,  and  maintain  elements,  and  user 
elements  that  permit  the  operational  military  forces  to  take  advantage  of 
the  capabilities  of  the  space  system.  Each  satellite  is  made  up  of  its 
elements,  typically  the  payload  (that  provides  the  basic  mission  capability 
such  as  communications,  surveillance,  navigation,  etc.)  and  the  spacecraft 
or  bus  (that  typically  supports  the  payload  by  providing  electrical  power, 
thennal  control,  and  attitude  control,  etc.).  The  payload  and  bus  are,  of 
course,  subdivided  into  lower  tier  elements  such  as  processors,  sensors, 
communications  (radios),  and  clocks  which  are  in  turn  made  up  of  parts 
(such  as  integrated  circuits,  relays,  or  roller  bearings)  and  materials  (such 
as  metallic  or  composite  structures),  all  fabricated  and  assembled  using 
various  processes. 

Similarly,  a  launch  system  is  typically  made  up  of  the  launch  vehicles 
(which  provide  the  initial  boost  toward  orbit),  upper  or  transfer  orbit 
stages  (which  place  the  satellite  in  or  near  its  operational  orbit),  ground 
control  and  monitoring  systems,  and  facilities  used  for  checking  out, 
mating,  and  supporting  the  launch  vehicles,  upper  stages,  and  satellites 
prior  to  launch.  Each  launch  vehicle  may  be  made  up  of  multiple  launch 
stages.  Each  launch  stage  and  upper  stage  is  typically  made  up  of 
propulsion,  guidance  and  control,  and  environmental  protection  elements. 

The  distinction  between  launch  systems  and  satellite  systems  is  not  always 
clear  such  as  the  case  of  the  Space  Shuttle  which  is  a  launch  system  that 
can  also  perform  or  support  operations  on  orbit  or  the  case  of  integral 
upper  stages  which  are  supplied  as  part  of  the  satellite  system  to  complete 
part  or  all  of  the  transfer  orbit  function  (Space  and  Missile  Systems  Center 
2005,  2). 

The  U.S.  has  the  capability  to  acquire  and  develop  many  types  of  space  systems; 
however,  they  would  not  be  useful  without  someone  to  operate  them.  United  States  space 
operations  fall  into  several  categories:  defense,  intelligence,  space  exploration  and  civil 
(Richelson  2008,  55).  Department  of  Defense  (DoD)  space  operations  fall  under  the 
auspices  of  AFSPC,  while  intelligence  space  operations  fall  under  the  National 
Reconnaissance  Office  (NRO).  The  National  Aeronautics  and  Space  Administration 
(NASA)  usually  conducts  research  space  operations,  while  civil  space  operations  are 
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conducted  by  various  businesses  and  can  include  missions  such  as  television  and 
communication  providers.  This  thesis  will  primarily  focus  on  DoD,  or  defense, 
operations,  however,  the  architecture  being  proposed  in  this  thesis  can  be  applied  to  any 
or  all  satellite  missions. 

The  following  provides  a  general  idea  of  how  space  operations  are  conducted 
based  on  this  researcher’s  experience  in  the  space  community.  For  DoD  operations,  the 
Joint  Space  Operations  Center  (JSpOC)  has  operational  command  (OPCOM)  over  all 
satellite  operations,  and  directs  missions  perfonned  by  various  space  operations 
squadrons  (SOPs).  The  SOPS  have  tactical  command  (TACOM)  over  their  respective 
satellites,  and  operate  from  space  operations  centers  (SOCs).  Usually  each  SOPs  has  a 
specific  mission.  For  example,  the  fourth1  SOPs  operate  the  protected  communications 
satellites  or  mission.  The  JSpOC  provides  direction  to  the  fourth  SOPs  on  various 
matters,  such  as  where  satellites  should  be  positioned,  users  to  support,  or  if  the  satellites 
need  to  be  decommissioned.  The  fourth  SOPs  in  turn,  provide  inputs  to  the  JSPOC  on 
how  missions  are  progressing  and  if  there  are  any  issues.  The  SOPs  generally  use  the 
ground  segment,  or  command  and  control  system,  to  control  the  satellites.  This  is  a 
limited  description  of  how  space  operations  work  in  AFSPC  but  provides  context  for 
readers  of  this  thesis. 

C.  PURPOSE  OF  STUDY:  NEED  FOR  SSA 

The  economic  and  military  might  of  the  U.S.  depends  on  the  availability  of 
technology  in  orbit.  SSA  is  the  key  to  protecting  these  vital  assets.  The  use  of  space  has 
become  so  important  for  military  operations  that  it  is  now  part  of  the  basic  USAF 
doctrine.  Some  key  contributions  of  space  noted  in  USAF  doctrine  are: 

•  “Space  power  bolsters  U.S.  global  presence”  (United  States  Air  Force  2001,  1) 

•  “Space  forces,  in  combination  with  air  and  information  capabilities,  offer  ever 
expanding  view  of  the  globe”  (United  States  Air  Force  2001,  1) 

•  “Integration  of  space-based  navigation  and  timing  systems  with  airborne 
platforms  has  enhanced  military  precision  strike  capability”  (United  States  Air 
Force  2001,  1) 
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•  “Synergistically  applied  with  other  forces,  space  provides  added  flexibility  in 
military  operations”  (United  States  Air  Force  2001,  2) 

SSA  in  particular  plays  a  significant  role  in  Counterspace  Operations  (United  States  Air 
Force  2004,  2). 

SSA  is  the  result  of  sufficient  knowledge  about  space-related  conditions, 
constraints,  capabilities,  and  activities — both  current  and  planned — in, 
from,  toward,  or  through  space.  Achieving  SSA  supports  all  levels  of 
planners,  decision  makers,  and  operators  across  the  spectrum  of  terrestrial 
and  space  operations.  SSA  involves  characterizing,  as  completely  as 
possible,  the  space  capabilities  operating  within  the  terrestrial  and  space 
environments.  SSA  information  enables  defensive  and  offensive 
counterspace  operations  and  forms  the  foundation  for  all  space  activities. 

It  includes  space  surveillance,  detailed  reconnaissance  of  specific  space 
assets,  collection  and  processing  of  intelligence  data  on  space  systems,  and 
monitoring  the  space  environment.  It  also  involves  the  use  of  traditional 
intelligence  sources  to  provide  insight  into  adversary  space  and 
counterspace  operations  (United  States  Air  Force  2004,  2). 

In  addition  to  the  above-mentioned  roles  of  SSA,  the  need  for  SSA  is  amplified 
due  to  the  fact  that  the  U.S.’s  space  advantage  has  eroded  over  the  past  several  decades 
(United  States  Air  Force  2004,  3).  “In  the  past,  the  U.S.  has  enjoyed  space  superiority 
through  our  technology  development  and  exploitation,  advanced  information  systems, 
and  robust  space  infrastructure”  (United  States  Air  Force  2004,  3).  However,  today  many 
other  countries  have  similar  capabilities  thanks  to  “technology  sharing,  materiel 
acquisition  and  purchase  of  space  services”  (United  States  Air  Force  2004,  4). 
Adversaries  today  have  both  symmetric  and  asymmetric  attack  capabilities  (United  States 
Air  Force  2004).  Methods  of  attack  include:  ground  system  attacks,  radio  frequency  (RF) 
jamming,  laser  systems  capable  of  interfering  with  satellites,  electromagnetic  pulse 
(EMP)  weapons  capable  of  degrading  or  destroying  satellite  and/or  ground  system 
electronics,  kinetic  antisatellite  (ASAT)  and  information  operation  capabilities  capable  of 
corrupting  space-based  computer  systems  (United  States  Air  Force  2004,  4).  All  of  these 
threats  justify  the  need  for  an  ability  to  conduct  SSA  to  protect  U.S.  space-based  assets. 

Furthermore,  if  all  space  capable  nations  continue  to  place  assets  in  space,  even 
with  only  peaceful  intentions,  the  U.S.  will  still  have  a  problem.  There  is  no  significant 
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effort  for  debris  removal  in  space  currently,  so  the  risks  of  collisions  will  continue  to 
increase  as  more  objects  occupy  the  same  usable  orbits  (Johnson  and  Zaman  2012,  3). 

D.  RESEARCH  QUESTIONS 

As  discussed  previously,  there  is  a  need  for  SSA  to  protect  U.S.  space  systems, 
and  this  need  will  only  increase  as  space  gets  more  congested.  Hosted  payloads  offer  one 
potential  way  to  continue  improving  the  U.S.  SSA  capability.  However,  just  placing 
hosted  payloads  on  satellites  will  not  solve  the  entire  SSA  problem.  Instead,  an 
architecture  must  be  developed  to  guide  the  deployment  of  these  sensors.  To  gain  a  better 
understanding  of  how  hosted  payloads  can  be  used  to  enhance  U.S.  SSA  capabilities,  this 
thesis  will  explore  the  following  two  questions: 

1)  What  are  the  requirements  for  an  individual  satellite  to  provide  local  SSA  using 
a  hosted  payload? 

•  Means  to  find  answer:  Perform  a  survey  of  hosted  payload  capabilities  and 
develop  a  generic  set  of  requirements  based  on  this  survey. 

2)  How  should  individual  SSA  payloads  be  distributed  to  provide  a  worldwide 
SSA  picture?  In  other  words,  what  should  the  architecture  look  like? 

•  Means  to  find  answer:  Use  STK  to  perform  a  simulation  of  hosted 
payloads  in  a  singular  orbital  plane.  From  this  data,  an  extrapolation  will 
be  made  on  how  a  worldwide  SSA  picture  could  be  provided  using  hosted 
payloads.  The  results  will  be  presented  in  an  Operational  View  -  1  (OV1) 
format. 

By  providing  an  SSA  picture  from  the  spacecraft’s  perspective  using  hosted 
payloads  and  using  data  fusion  to  provide  a  global  SSA  perspective,  this  thesis  seeks  to 
discover  if  the  paradigm  of  SSA  can  be  shifted  from  a  catalog  based  mindset  to  a  truly 
global  SSA  mindset  (Johnson  and  Zaman  2012,  2).  A  global  mindset,  as  related  to  SSA, 
is  one  that  takes  into  account  not  only  catalog  data,  but  data  provided  by  onboard  sensors 
as  well  and  has  been  fused  to  provide  greater  synergies  than  if  the  data  were  presented 
alone.  By  shifting  to  a  global  mindset,  the  U.S.  will  not  only  increase  its  ability  to  track 
and  identify  space  objects;  it  will  continue  to  maintain  U.S.  dominance  in  space. 
Maintaining  U.S.  dominance  in  space  would  mean  the  continued  freedom  to  operate  not 
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only  in  space,  but  also  throughout  the  world,  since  space  supports  all  aspects  of  U.S. 
operations  (U.S.  Strategic  Command  2012,  3). 

E.  BENEFITS  OF  STUDY 

This  study  will  provide  a  rationale  for  using  hosted  payloads  to  provide  SSA  on 
DoD  systems.  Additionally,  the  simulation  performed  in  this  study  will  attempt  to 
quantify  how  many  systems  would  need  to  be  deployed  to  provide  a  worldwide  SSA 
picture  using  hosted  payloads.  Using  the  results  of  this  thesis,  a  space  program  office 
within  the  DoD  could  develop  a  tailored  set  of  requirements  to  put  a  hosted  SSA  payload 
on  a  satellite  being  acquired.  Furthermore,  if  a  program  office  is  launching  multiple 
satellites,  the  results  of  this  thesis  may  be  used  to  help  detennine  how  many  hosted  SSA 
payloads  would  be  required  to  ensure  an  entire  constellation  is  protected.  Finally,  this 
thesis  could  provide  policy  makers  with  a  basis  to  provide  funding  for  future  acquisitions, 
and  possibly  develop  a  mandate  to  have  onboard  SSA  capabilities  on  all  space  systems. 

F.  SCOPE  AND  METHODOLOGY 

1.  Scope 

For  this  thesis,  the  scope  of  the  requirements  analysis  and  payload  distribution 
study  will  be  bounded  to  a  single  orbital  plane  in  LEO.  The  LEO  orbit  was  chosen  due  to 
the  high  number  of  satellites  in  this  orbit  when  compared  to  other  orbits.  A  single  orbital 
plane  was  chosen  due  to  the  fact  that  the  results  from  one  orbital  plane  can  be 
extrapolated  and  applied  to  other  orbits  if  desired.  However,  it  should  be  noted,  there  may 
be  other  considerations  if  multiple  planes  are  analyzed.  This  could  include,  but  is  not 
limited  to,  how  satellites  orbiting  in  various  planes  intersect  or  what  different  sensor 
capabilities  are  needed  to  monitor  in  multiple  planes. 

2.  Methodology 

The  approach  for  accomplishing  this  study  involved  three  phases.  The  first  phase 
of  this  study  started  with  a  survey  of  various  hosted  payload  and  sensor  capabilities. 
Mostly,  the  research  focused  on  hosted  payload  studies  and  programs  conducted  by  Air 
Force  Space  Command,  due  to  AFSPC  being  the  focal  point  for  space  systems  in  the  U.S. 
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government.  However,  research  conducted  by  NASA,  private  industry  and  academia  was 
also  evaluated. 

One  program  that  got  intense  focus  during  the  first  phase  of  this  research  was  the 
Self  Aware  Space  Situational  Awareness  (SASSA)  program.  This  was  primarily  due  to 
the  fact  that  the  author  of  this  thesis  was  the  USAF  Program  Manager  (PM)  for  this 
program.  As  the  PM,  the  author  of  this  thesis  oversaw  the  SASSA  program  from  Critical 
Design  Review  (CDR)  through  launch  and  operations,  and  has  an  intimate  understanding 
of  how  the  SASSA  hosted  payload  requirements  were  developed  and  the  capability 
fielded. 

In  the  second  phase,  using  information  gleaned  from  Phase  One,  a  generic  set  of 
requirements  for  a  hosted  SSA  payload  was  developed.  While  this  set  of  requirements  is 
not  all  encompassing,  it  provides  a  sound  basis  for  developing  a  set  of  requirements  that 
can  be  tailored  for  a  particular  space  mission. 

Finally,  in  the  third  phase,  the  requirements  developed  for  the  hosted  SSA 
payload  were  input  into  a  STK  simulation.  The  simulation  was  run  to  determine  how 
many  hosted  SSA  payloads  would  be  required  in  a  single  orbital  plane  to  provide  a 
“global”  SSA  picture.  This  simulation  assumed  that  a  data  fusion  capability  to  integrate 
the  data  from  the  propagated  payloads  already  existed  and  was  not  taken  into  account  for 
this  thesis.  Once  the  simulation  was  completed,  an  OV-1  was  developed. 
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II.  SYSTEMS  ENGINEERING  METHODOLOGY 


A.  INTRODUCTION 

As  capabilities  and  technologies  have  progressed  in  the  DoD,  the  practices  and 
standards  across  the  various  aspects  of  systems  engineering  and  program  management 
have  been  defined  as  standards.  These  standards,  set  out  for  industry  and  DoD  acquisition 
organizations,  provide  a  standard  roadmap  to  follow  and  help  ensure  a  successful 
acquisition.  Systems  engineering  will  be  used  in  this  thesis  to  ensure  the  various  aspects 
of  the  research  questions  are  taken  into  account. 

B.  GENERAL  SYSTEMS  ENGINEERING 

The  area  of  systems  engineering,  in  general,  is  rooted  in  two  areas:  program 
management  and  technical  engineering  (Blanchard  and  Fabrycky  2011,  17-18).  Due  to 
this  twofold  focus,  systems  engineering  provides  essential  inputs  to  execute  effective 
technical  designs,  as  well  as  manage  a  program  successfully  (Blanchard  and  Fabrycky 
2011,  17-18).  Unlike  ground  systems,  space  systems  typically  only  have  a  single  chance 
at  success.  A  failed  launch  usually  means  a  failed  system  and/or  mission.  For  this  reason, 
in  space  systems  acquisition,  systems  engineering  is  used  in  every  aspect  of  the 
acquisition  to  ensure  the  system  will  work  correctly  upon  launch. 

The  definition  for  systems  engineering  is  not  set  in  stone.  Unlike  the  hard 
engineering  disciplines  such  as  electrical,  civil  and  mechanical  engineering,  systems 
engineering  is  based  on  a  more  holistic  foundation.  Systems  engineering  looks  at  an 
object,  or  system,  consisting  of  interrelated  or  interacting  elements  instead  of  focusing  on 
a  single  item  as  the  other  disciplines  might  (Nelson  2013,  28).  By  surveying  various 
descriptions  of  systems  engineering,  an  adequate  definition  for  systems  engineering  can 
be  obtained.  Standard  definitions  of  systems  engineering  include: 

1.  An  interdisciplinary  approach  and  means  to  enable  the  realization  of 

successful  systems  (International  Council  on  Systems  Engineering  2004). 

2.  An  interdisciplinary  approach  encompassing  the  entire  technical  effort 

to  evolve  into  and  verily  an  integrated  and  life-cycle  balanced  set  of 
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system  people,  product,  and  process  solutions  that  satisfy  customer  needs. 
Systems  engineering  encompasses  (a)  the  technical  efforts  related  to  the 
development,  manufacturing,  verification,  deployment,  operations, 
support,  disposal  of  ,  and  user  training  for,  systems  products  and 
processes;  (b)  the  definition  and  management  of  the  system  configuration 
(c)  the  translation  of  the  system  definition  into  work  breakdown  structures; 
and  (d)  development  of  information  for  management  decision  making 
(Blanchard  and  Fabry cky  2011,  17). 

3.  The  application  of  scientific  and  engineering  efforts  to  (a)  transform  an 
operational  need  into  a  description  of  system  performance  parameters  and 
a  system  configuration  through  the  use  of  an  iterative  process  of 
definition,  synthesis,  analysis,  design,  test,  and  evaluation;  (b)  integrate 
related  technical  parameters  and  ensure  compatibility  of  all  physical, 
functional  and  program  interfaces  in  a  manner  that  optimizes  the  total 
system  definition  and  design;  and  (c)  integrate  reliability,  maintainability, 
safety,  survivability,  human  engineering,  and  other  such  factors  into  the 
total  engineering  effort  to  meet  cost,  schedule  supportability  and  technical 
performance  objectives  (Kockler,  et  al.  1990,  16) 

4.  An  interdisciplinary  collaborative  approach  to  derive,  evolve,  and  verify 
a  life-cycle  balanced  system  solution  which  satisfies  customer 
expectations  and  meets  public  acceptability  (IEEE  1998,  10). 

5.  An  approach  to  translate  operational  needs  and  requirements  into 
operationally  suitable  blocks  of  systems.  The  approach  shall  consist  of  a 
top-down,  iterative  process  of  requirements  analysis,  functional  analysis 
and  allocations,  design  synthesis  and  verification,  and  systems  analysis 
and  control.  Systems  engineering  shall  permeate  design,  manufacturing, 
test  and  evaluation,  and  support  of  the  product.  Systems  engineering 
principles  shall  influence  the  balance  between  performance,  risk,  costs, 
and  schedule  (Defense  Acquisition  University  2009,  2). 

As  one  can  see  from  the  descriptions  above,  there  are  a  variety  of  definitions  for 
systems  engineering.  Some  are  concise,  while  others  discuss  the  many  facets  of  systems 
engineering.  While  the  definitions  from  the  various  sources  differ  somewhat,  one  can  also 
observe  common  themes.  These  commonalities  include: 

1.  A  top-down  approach  that  views  the  system  as  a  whole.  Although 
engineering  activities  in  the  past  have  adequately  covered  the  design  of 
various  system  components  (representing  a  bottom-up  approach),  the 
necessary  overview  and  understanding  of  how  these  components 
effectively  perform  together  is  frequently  overlooked  (Blanchard  and 
Fabrycky  2011,  18). 
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2.  A  life-cycle  orientation  that  addresses  all  phases  to  include  system 
design  and  development,  production  and/or  construction,  distribution, 
operation,  maintenance  and  support,  retirement,  phase-out,  and  disposal. 
Emphasis  in  the  past  has  been  placed  primarily  on  design  and  system 
acquisition  activities,  with  little  (if  any)  consideration  given  to  their 
impact  on  production,  operations,  maintenance,  support,  and  disposal.  If 
one  is  to  adequately  identify  risks  associated  with  the  up-front  decision 
making  process,  then  such  decisions  must  be  based  on  life-cycle 
considerations  (Blanchard  and  Fabrycky  2011,  18). 

3.  A  better  and  more  complete  effort  is  required  regarding  the  initial 
definition  of  system  requirements,  relating  these  requirements  to  specific 
design  criteria,  and  the  follow-on  analysis  effort  to  ensure  the 
effectiveness  of  early  decision  making  in  the  design  process.  The  true 
system  requirements  need  to  be  well  defined  and  specified  and  the 
traceability  of  these  requirements  from  the  system  level  downward  needs 
to  be  visible.  In  the  past,  the  early  “frontend”  analysis  as  applied  to  many 
new  systems  has  been  minimal.  The  lack  of  defining  an  early  “base  line” 
has  resulted  in  greater  individual  design  efforts  downstream  (Blanchard 
and  Fabrycky  2011,  18) 

4.  An  interdisciplinary  team  approach  throughout  the  system  design  and 
development  process  to  ensure  that  all  design  objectives  are  addressed  in 
an  effective  and  efficient  manner.  This  requires  a  complete  understanding 
of  many  different  design  disciplines  and  their  interrelationships,  together 
with  the  methods,  techniques,  and  tools  that  can  be  applied  to  facilitate 
implementation  of  the  system  engineering  process  (Blanchard  and 
Fabrycky  2011,  18). 

In  summary,  systems  engineering  is  not  the  same  as  traditional  engineering 
disciplines.  Instead  it  is  a  process  that  provides  a  well  thought  out  and  highly  disciplined 
and  rigorous  approach  to  fielding  systems.  Instead  of  looking  at  one  part  of  an 
acquisition,  systems  engineering  looks  at  the  entire  life  cycle  and  uses  an 
interdisciplinary  approach  to  achieve  objectives. 

For  this  thesis,  a  systems  engineering  approach  will  be  applied  to  address 
objectives  effectively  and  efficiently.  A  top  down  approach  will  be  taken,  to  view  the 
SSA  system  as  a  whole,  rather  than  separate  components.  By  utilizing  this  approach,  an 
architecture  can  be  developed  to  provide  a  “global”  SSA  system. 
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C.  SPACE  SYSTEMS  ENGINEERING 

Up  to  this  point,  systems  engineering  has  only  been  discussed  in  general  terms. 
Since  this  thesis  is  focused  on  space  systems,  there  are  some  nuances  about  space 
systems  engineering  that  must  be  addressed  as  well.  The  Space  and  Missiles  Systems 
Center  (SMC)  is  the  USAF’s  acquisition  organization  for  space  systems.  Since  this 
researcher  is  assigned  to  SMC,  SMC  documentation  was  primarily  used  for  research  in 
this  thesis.  It  should  be  noted,  there  are  other  sources  to  obtain  space  systems  engineering 
knowledge,  such  as  NASA,  other  DoD  components  and  the  Aerospace  Corporation.  For 
the  purposes  of  this  thesis,  these  sources  were  reviewed  but  are  not  discussed  here.  This 
is  due  to  the  fact  that  the  sources  reviewed  provided  similar  guidance  as  the  SMC 
guidance. 

The  main  source  used  for  space  systems  engineering  was  a  SMC  developed  guide 
for  systems  engineering  within  the  space  context,  the  SMC  Systems  Engineering  Primer 
&  Handbook.  Within  this  handbook,  three  areas  are  highlighted  for  space  systems,  which 
are  different  from  other  DoD  systems.  The  first  is  “the  space  environment”  (Space  and 
Missile  Systems  Center  2005,  2). 

The  space  environment  places  additional  constraints  on  the  satellites  and 
the  components  and  parts  that  make  up  the  system  -  near  total  vacuum, 
ambient  thermal  inputs  varying  from  direct  sun  illumination  in  one 
direction  to  the  near  absolute  zero  of  deep  space  in  others,  and  passage 
through  belts  of  charged  particles  to  name  three.  These  constraints  must  be 
characterized,  and  the  hardware  must  be  designed  to  survive  and  operate 
in  space.  Special  test  facilities  such  as  thermal  vacuum  chambers  are 
required  to  verily  that  the  hardware  can  operate  in  the  environment.  In 
addition,  high  vibration,  acoustic,  shock,  and  other  environments  during 
launch  and  deployment  into  the  operational  orbit  require  careful 
characterization,  design,  and  testing  to  prevent  irretrievable  failures  during 
launch  and  early  on-orbit  operations. 

For  the  system  being  proposed  in  this  thesis,  the  space  environment  will  be 
considered  and  accounted  for  in  the  architecture  and  requirements.  This  thesis  will  not  go 
into  depth  on  meeting  specific  target  values  for  each  environmental  factor  and  will  only 
account  for  them  in  general  terms. 
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The  second  area  that  must  be  considered  is  a  reality  with  space  systems  that 
doesn’t  usually  apply  to  land  or  air  based  systems:  this  is  the  fact  that  most  systems  must 
have  unattended  operations,  and  remain  in  service  with  very  limited  ability  to  fix 
hardware  issues  (Space  and  Missile  Systems  Center  2005,  3). 

The  space  based  elements  of  all  military  space  systems  developed  so  far 
operate  unattended.  For  that  reason,  if  a  component  fails,  only  remote 
maintenance  actions  can  be  carried  out.  Such  actions  must  usually  be 
preplanned  and  take  advantage  of  provisions  designed  into  the  hardware 
such  as  redundant  hardware  or  re-loadable  software.  As  a  result,  satellites 
are  usually  designed  to  eliminate  (or  at  least  minimize)  single  point 
failures.  Also,  redundancy  has  been  increasingly  designed  into  launch 
systems.  When  the  redundant  hardware  also  fails,  the  satellite  may  no 
longer  provide  the  intended  capability.  Therefore,  high  reliability  parts  are 
also  used.  Further,  care  is  taken  to  verify  that  the  hardware  has  a  positive 
margin  with  respect  to  the  launch  and  space  environments  described 
above.  When  a  software  defect  affects  operation,  the  satellite  must  usually 
be  capable  of  being  placed  in  a  safe  mode  until  the  defect  can  be  identified 
and  corrected.  Therefore,  software  that  could  cause  the  irretrievable  loss  of 
a  mission  is  validated  through  such  steps  as  extensive  simulations, 
sometimes  with  flight  hardware  in  the  loop.  Experience  shows  that  the 
cost  of  these  steps  together  with  the  cost  of  space  launch  is  perhaps  ten 
times  or  more  the  cost  of  comparable  hardware  deployed  in  terrestrial 
applications.  Balancing  such  factors  as  perfonnance,  cost,  and  reliability  is 
a  systems  engineering  task  for  all  systems,  but  the  high  cost  of  space 
equipment  places  an  extraordinary  premium  on  balancing  the  operational 
capability  to  be  provided  with  other  factors  such  as  cost,  reliability,  and 
service  life.  To  achieve  balance,  alternative  approaches  or  concepts  must 
be  compared  or  traded  off  against  each  other  with  respect  to  effectiveness, 
affordability,  and  risk  (Space  and  Missile  Systems  Center  2005,  3). 

There  is  the  remote  possibility  that  astronauts  could  service  a  failed  component; 
however,  for  such  a  scenario  to  arise,  the  benefits  would  have  to  be  significant.  As  such  a 
scenario  is  highly  unlikely,  it  will  not  be  considered  as  a  possibility  in  this  thesis.  The 
requirements  developed  in  this  thesis  will  intend  for  the  system  to  confonn  to  unattended 
operations  as  described  above. 

The  final  consideration  one  must  take  into  account  about  space  systems  is  the  fact 
that  space  is  the  ultimate  high  ground  (Space  and  Missile  Systems  Center  2005,  3). 
Because  of  this,  space  systems  are  subject  to  a  unique  set  of  constraints  due  to  their  high 
costs,  and  desire  for  multiple  forces — air,  land  and  sea — to  use  them  (Space  and  Missile 
Systems  Center  2005,  3) 
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Military  forces  have  strived  for  the  high  ground  for  millennia  because  of 
the  advantages  it  provides  including  the  increased  ability  to  observe  or 
survey  the  enemy  and  the  operational  environment,  maintain  line  of  sight 
communications  with  friendly  forces,  and  orient  oneself  with  respect  to 
the  enemy  and  the  surrounding  terrain.  Space  provides  the  ultimate  high 
ground  so  it  is  not  surprising  that  current  military  space  systems  provide 
for  surveillance  of  both  potential  enemies  and  the  meteorological 
conditions  in  the  operational  theatre  as  well  as  communications  and 
navigation.  New  systems  are  being  planned  or  under  development  to 
extend  these  capabilities.  But  the  cost  to  build  and  launch  satellites  means 
that  each  must  be  exploited  to  the  extent  practical  by  all  land,  sea,  and  air 
forces.  As  a  result,  many  of  the  space  programs  are  joint  programs  to 
provide  capability  to  be  used  by  in  joint  operations  by  elements  of  all  the 
military  forces.  The  user  equipment  for  such  systems  can  become 
deployed  on  a  wide  range  of  platforms  and  therefore  rival  or  even  exceed 
the  cost  of  the  satellites  and  launch  vehicles  so  that  the  systems 
engineering  task  of  balancing  effectiveness  and  cost  can  be  still  more 
demanding  and  important.  The  extreme  example  is  the  Global  Positioning 
System  (GPS)  that  provides  navigation  data  via  user  equipment  carried 
directly  by  military  personnel  and  on  most  of  the  thousands  of  land,  naval, 
and  air  platfonns  operated  by  the  Department  of  Defense  (and  also  used  in 
a  wide  range  of  civil  and  private  applications)  (Space  and  Missile  Systems 
Center  2005,  3). 

If  a  worldwide-hosted  payload  architecture  is  adopted,  then  there  will  be 
possibility  that  multiple  users  would  benefit  from  the  data.  While  the  primary  mission  of 
the  hosted  payload  would  be  to  provide  SSA,  one  can  imagine  a  scenario  where  the  data 
could  be  mined  for  other  uses,  such  as  by  the  intelligence  community.  As  described 
above,  the  system  requirements  will  need  to  account  for  this  possibility. 

Due  to  these  three  unique  areas  that  apply  to  space  systems  engineering,  tasks  that 
are  routine  on  most  programs  become  increasingly  difficult  on  space  systems.  The  system 
boundary  is  much  wider,  and  as  such,  the  application  of  systems  engineering  must  be  all 
encompassing  as  well.  In  this  thesis,  this  researcher  will  apply  a  comprehensive  systems 
engineering  process  to  ensure  general  and  space  specific  concerns  are  taken  into 
consideration. 
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III.  PROBLEM  DEFINITION 


A.  CURRENT  CAPABILITIES 

To  understand  the  type  of  system  that  would  be  needed  to  perform  a  SSA  mission 
using  hosted  payloads,  research  was  conducted  to  determine  the  types  of  capabilities 
were  currently  in  use.  Current  SSA  architecture,  hosted  payloads  and  various  sensors 
were  reviewed.  During  the  research,  sources  from  within  various  government  entities 
were  evaluated  including  AFSPC  and  NASA.  Additionally,  industry  and  academia 
sources  were  considered. 

As  far  as  SSA  architecture  is  concerned,  AFSPC  was  the  authoritative  source  for 
current  capabilities.  There  is  an  existing  SSA  architecture  known  in  the  DoD  as  the  U.S. 
Space  Surveillance  Network  (SSN).  The  U.S.  primarily  leverages  the  SSN,  a  system  of 
radar  and  optical  ground  sites  positioned  around  the  globe,  to  form  its  SSA  architecture 
(Levin  2002).  Figure  4  depicts  the  locations  of  the  U.S.  SSN  ground  sites. 


Figure  4.  U.S.  Space  Surveillance  Network  (From  Johnson  and  Zaman  2012) 


The  radars  feed  into  the  JSpOC,  along  with  data  collected  from  SBSS  and  other 

contributing  sensors  to  form  the  space  catalog.  These  items  form  the  basic  components  of 

the  U.S.  SSA  architecture.  While  this  architecture  provides  SSA,  it  differs  in  approach 

from  what  this  thesis  is  advocating.  Additionally,  the  architecture  discussed  here  has 
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limitations.  By  using  primarily  ground  sites,  there  are  limitations  with  respect  to  field  of 
view,  weather,  over  flight,  range,  and  resolution.  (Weeden  2009,  4).  Field  of  view  is 
limited  due  to  the  fact  that  a  radar  or  optical  site  positioned  at  a  particular  point  on  Earth 
can  only  see  what  its  aperture  allows.  If  there  is  inclement  weather,  limitations  can  be 
introduced  into  the  radar  and  optical  sites.  Radars  can  be  affected  by  precipitation 
depending  on  their  operating  frequency.  Optical  sites  are  susceptible  to  limitations  if 
there  are  clouds  blocking  the  field  of  regard.  When  a  radar  or  optical  site  is  a  fixed  site, 
i.e.,  cannot  be  repositioned,  then  over  flight  limitations  become  a  concern.  The 
particular  sites  can  only  be  useful  when  a  satellite  is  flying  over  the  particular  site.  Range 
becomes  a  concern  depending  on  the  altitude  of  a  particular  spacecraft.  While  LEO  orbits 
are  not  difficult  to  monitor  with  radar  and  optical  sites,  GEO  orbits  are  orders  of 
magnitude  more  difficult  to  monitor,  as  objects  can  be  more  than  35,000  km  away. 
Finally,  resolution  of  images  captured  is  a  concern  with  ground  sites.  Since  the  resolution 
on  grounds  sites  is  limited  by  the  radar  aperture  or  focal  plane  of  the  optic,  there  are  times 
objects  can  be  not  detected  or  are  mischaracterized  (Weeden  2009,  4-7). 

With  respect  to  hosted  payloads,  there  were  two  government  organizations 
perusing  hosted  payloads  in  a  continuing  manner,  NASA  and  the  USAF.  Additionally, 
there  are  other  government  organizations  that  have  already  utilized  hosted  payloads  on  a 
limited  basis.  The  organizations  that  have  used  hosted  payloads  on  a  limited  basis  include 
the  Federal  Aviation  Administration  (FAA),  ET.S.  Coast  Guard  (USCG)  and  DoD.  These 
payloads  were  hosted  on  satellites  to  support  various  missions  and  supported  this  thesis’s 
assertion  that  cost  savings  are  achievable  by  using  hosted  payloads  (Andraschko,  Antol 
and  Baize,  et  al.  2012,  2). 

The  FAA  system  was  the  Wide  Area  Augmentation  System  (WAAS).  WAAS  was 
developed  to  provide  extremely  accurate  navigation  for  civil  aviation  from  space  in 
conjunction  with  GPS  satellites.  Originally,  the  FAA  had  utilized  a  Ground  Based 
Augmentation  System  (GBAS).  However,  similar  to  the  on  ground  sites  on  the  SSN, 
there  were  limitations  in  coverage  in  the  national  air  space  using  ground-based  assets. 
Due  to  these  limitations,  the  FAA  began  developing  hosted  payloads  to  be  flown  on  GEO 
based  satellites,  which  would  alleviate  the  limitations  of  GBAS.  These  payloads  were 
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hosted  on  three  commercial  satellites:  Inmarsat-4  F3,  Telesat’s  Anik  FIR  and  Intelsat’s 
Galaxy  15.  Instead  of  having  to  develop  independent  satellites  at  great  costs,  the  FAA 
was  able  to  utilize  available  space  on  commercial  satellites  to  pursue  their  mission.  The 
hosted  payloads  have  been  a  success  for  the  FAA  and  currently  provide  navigation 
continuously  while  maintaining  the  strictest  safety  standards  (Federal  Aviation 
Adminstration  2010,  1).  Figure  5  depicts  the  WAAS  system  graphically  and  Figure  6 
depicts  the  current  footprints  for  the  three  hosted  payloads. 


WAAS  ^  Gpsstei tes 

wme  area  augmentation  system 


GEO  Satellite 


j  Sjt  Juan 


v  Wide-area  Reference  Station  (WRS)  %  New  WRS's 
5  Wide-area  Master  Station  (WMS)  ^  Ground  Uplink  Station 


jGEO  Satellite 


Figure  5.  Wide  Area  Augmentation  System  (From  Federal  Aviation  Adminstration 

2010) 
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Figure  6.  WAAS  Footprint  (From  Federal  Aviation  Adminstration  2010) 

The  USCG’s  Nationwide  Automatic  Identification  System  (NAIS)  is  another 
example  of  a  low  cost  solution  to  a  potentially  high  cost  problem.  The  USCG  needed  a 
system  to  monitor  data  from  maritime  traffic,  including  vessel  location,  source  and  speed. 
Ship-based  transponders  typically  can  only  transmit  about  46  miles  horizontally. 
However,  vertically  these  same  transponders  have  reached  the  international  space  station 
orbiting  around  400  km.  By  utilizing  space  based  hosted  payloads  on  spacecraft  such  as 
the  International  Space  Station  (ISS),  ORBCOMM  and  Luxspace’s  RUBIN-9.1,  the 
USCG  avoided  having  to  deploy  costly  land  based  systems  along  the  entire  coastline,  and 
increased  the  usable  range  of  the  transponders.  Additionally,  by  utilizing  space-based 
systems,  the  USCG  was  able  to  form  a  comprehensive  view  of  traffic  on  the  nation’s 
waterways;  this  better  prepares  decision  makers  in  case  there  is  an  emergency  (United 
States  Coast  Guard  2013,  1). 

The  Department  of  Defense,  in  conjunction  with  Cisco  Systems,  built  a  hosted 

payload  to  demonstrate  Internet  Routing  in  Space  (IRIS).  IRIS  was  a  radiation  tolerant  IP 

router  created  as  a  hosted  payload  and  launched  on  Intelsat-14  in  GEO.  Again,  a  hosted 

payload  was  employed  to  demonstrate  a  technology.  While  this  payload  did  not  provide 

SSA,  it  was  able  to  accomplish  a  mission  separate  from  the  primary  host.  Additionally, 
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the  reduced  timeline  of  the  hosted  payload  enabled  Cisco  and  DoD  to  take  advantage  of 
the  commercial  satellite’s  design,  development  and  launch  cycle.  Figure  7  shows  a 
picture  of  the  small  IRIS  payload  developed  (INTELSAT  General  Corporation  2013). 


Figure  7.  IRIS  Payload  (From  INTELSAT  General  Corporation  2013) 

Until  2010,  NASA  had  yet  to  utilize  hosted  payloads  in  a  significant  way 
(Andraschko,  Antol  and  Horan,  et  al.  2011,  2).  However,  in  late  2010,  NASA  started 
exploring  the  possibilities  of  using  hosted  payloads.  This  was  primarily  due  to  the  fact 
that  hosted  payloads  offer  multiple  benefits  for  government  payloads.  Benefits  include: 
lower  costs,  frequent  launch  opportunities,  and  leveraging  of  existing  infrastructure.  The 
lower  costs  were  a  significant  contributor  for  NASA  to  pursue  hosted  payloads,  due  to 
diminishing  budgets.  For  NASA’s  approach,  the  target  hosts  for  hosting  payloads  were 
commercial  satellites.  This  is  mainly  due  to  the  flexibility  offered  with  commercial 
providers  and  the  steady  launch  cycles  (Andraschko,  Antol  and  Baize,  et  al.  2012,  1). 
Commercial  programs  are  not  subject  to  election  cycle  politics  or  congressional 
budgeting  actions,  which  can  change  government  launch  schedules  at  any  time. 
Commercial  spacecraft  providers  see  benefits  from  hosted  payloads  as  well.  A  major 
benefit  is  the  financial  advantage  a  government  customer  brings  to  the  picture.  Typically 
commercial  providers  receive  steady  funding  from  government  customers  due  to  laws  in 
place  such  as  the  Anti-deficiency  Act  (U.S.  Government  Accountability  Office  2006). 
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A  major  sign  hosted  payloads  are  making  inroads  within  NASA  is  the  release  in 
August  2010  of  NASA’s  Hosted  Payload  Guidebook  (Futron  Corporation  2010).  Within 
the  guidebook,  NASA  had  devised  a  step-by-step  process  for  developing  hosted 
payloads.  The  areas  covered  in  the  guidebook  are: 

•  Purpose/Rationale  for  the  Guidebook 

•  Technical  Issues 

•  Contractual  Issues 

•  Payload  Integration  and  Pre-Launch  Activities 

•  Launch  and  On-Orbit  Testing 

•  Operational  Phase  and  End  of  Life  Activities 

The  depth  and  breadth  discussed  in  the  guidebook  provides  a  one-stop  shop  for  hosted 
payload  development  within  NASA  and  is  a  promising  sign  that  hosted  payloads  will 
gain  significant  traction  within  the  NASA  community  (Futron  Corporation  2010,  3). 

A  further  sign  that  NASA  is  marching  down  the  path  of  utilizing  more  hosted 
payloads  is  the  number  of  hosted  payloads  being  built.  Currently  NASA  has  several 
unclassified  hosted  payloads  in  development  and  preparing  for  launch.  The  first  is  the 
$55  million  Global-scale  Observations  of  the  Limb  and  Disk  (GOLD),  which  is 
scheduled  to  launch  on  a  SES  Government  Solutions  commercial  satellite.  “Gold  will  fly 
an  ultraviolet  imaging  spectrograph  on  a  geostationary  satellite  to  measure  densities  and 
temperatures  in  the  Earth’s  thermosphere  and  ionosphere”  (U.S.  Depepartment  of 
Commerece  2013,  1).  Another  NASA-hosted  payload  being  developed  is  the 
Multispectral  Imaging  System  for  the  Thermosphere  and  Ionosphere  (MISTI).  This 
payload  is  to  be  launched  on  an  Intelsat  commercial  satellite.  Finally,  the  Thermosphere 
Ionosphere  Global  and  Regional  Imaging  System  (TIGRIS)  is  also  being  developed  for 
launch  on  an  Intelsat  commercial  satellite  (U.S.  Depepartment  of  Commerece  2013,  2). 

The  Air  Force,  on  the  other  hand,  started  discussions  of  using  hosted  payloads  in 
late  2007  with  the  requirements  being  released  for  the  SASSA  program.  Previous  to  this 
instance,  there  had  been  other  hosted  payloads  attempted;  however,  SASSA  was  the  first 
concentrated  effort  to  develop  a  standardized  hosted  payload  which  could  be  fielded  on 
multiple  host  satellites.  This  hosted  payload  was  meant  to  be  tailorable  to  any  desired 
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mission  and  could  be  fielded  to  do  a  number  of  tasks.  The  primary  vision  for  SASSA  had 
been  a  SSA  payload.  SASSA  included  a  common  interface  unit  (CIU),  which  allowed  for 
various  instruments  to  be  plugged  into  it.  SASSA’s  original  plan  called  for  a  single 
technology  demonstration  system  to  be  developed,  tested  and  launched.  After  a 
successful  technology  demonstration,  the  SASSA  system  was  to  be  further  refined;  its 
size,  weight  and  power  (SWAP)  reduced,  and  fielded  across  all  U.S.  satellites.  However, 
due  to  changing  budget  conditions  within  the  U.S.  government,  only  the  technology 
demonstration  was  fielded.  The  remainder  of  the  SASSA  plan  was  shelved  for  the 
foreseeable  future,  and  no  production  systems  have  been  built  to  date.  The  single  system 
fielded,  however,  did  do  a  tremendous  job  in  advancing  SSA  capabilities.  The  system 
launched  had  SSA  sensors  integrated  and  a  ground  system  was  fielded  as  well.  The 
integration  process  onto  the  host  spacecraft  was  noted  in  SMC  as  being  one  of  the 
smoothest  integrations  ever;  which  is  hard  to  come  by  when  one  is  dealing  with  space 
systems  (Johnson  and  Zaman  2012,  2-7).  Another  indication  that  the  USAF  wanted  to 
pursue  hosted  payloads  was  the  transfer  of  data  and  lessons  learned  from  the  SASSA 
program  office  to  the  Hosted  Payload  Office  at  SMC.  At  the  time  of  this  thesis  being 
written,  this  author  has  first-hand  knowledge  that  the  Hosted  Payload  Office  is  continuing 
development  of  various  hosted  payloads  and  is  considering  the  lessons  learned  from 
SASSA  for  future  development  efforts. 

At  the  same  time  as  SASSA  was  being  fielded,  another  program  by  the  name  of 
CHIRP,  Commercially  Hosted  Infrared  Payload,  was  also  being  developed  by  the  USAF 
at  SMC.  While  CHIRP  was  not  intended  to  be  a  SSA  payload,  i.e.,  it  was  an  infrared  (IR) 
payload,  it  was  still  developed  as  a  hosted  payload.  CHIRP  was  successful  in 
demonstrating  that  a  military  payload  could  be  hosted  on  a  commercial  satellite.  CHIRP’s 
success  contributed  to  the  creation  of  the  Hosted  Payload  Office  in  the  Development 
Planning  Directorate  at  SMC.  The  Hosted  Payload  Office  helps  push  the  USAF’s  drive  to 
develop  less  expensive  and  more  quickly  field  options  for  space  missions  (Simonds  and 
Sullivan  2010,  3). 
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Finally,  on  the  subject  of  sensors  that  can  provide  SSA,  much  of  the  specific  data 
found  was  sensitive  and  not  available  to  be  published  due  to  security  restrictions. 
However,  in  general  there  are  several  SSA  sensors  that  can  be  used.  These  include: 

•  Radar  warning  receivers  (RWR) 

•  Laser  warning  receivers  (LWR) 

•  Environmental  sensors 

•  Proximity  sensors 

•  Imaging  sensors 

All  of  these  instruments  can  be  fielded  as  a  hosted  payload  or  integrated  into  a  package 
(e.g.  SASSA’s  methodology).  For  the  purposes  of  this  thesis,  generic  capabilities  will  be 
used  in  the  analysis  and  presented  later  in  this  thesis.  No  specific  sensor’s  attributes  were 
leveraged  to  perform  the  payload  propagation  simulation  and  architecture  study. 

B.  STAKEHOLDER  ANALYSIS 

A  stakeholder  analysis  was  conducted  as  part  of  this  thesis.  Because  space  is  a 
domain  that  is  utilized  by  almost  everyone,  with  or  without  their  knowledge,  there  are  a 
multitude  of  stakeholders.  Table  1  lists  the  major  stakeholders  derived  from  the  analysis. 
Additionally,  the  major  stakeholders  were  divided  into  three  sectors:  government,  private 
and  public.  The  criteria  used  for  a  major  stakeholder  was  the  stakeholder  would  derive  a 
direct  benefit  from  hosted  SSA  payloads.  Examples  of  direct  benefits  include  saving  an 
ailing  spacecraft,  receiving  a  contract  to  build  a  payload,  continued  use  of  a  space  asset  or 
intelligence  benefits.  Minor  stakeholders,  such  as  subcontractors  that  may  make  minor 
parts  on  a  SSA  payload,  were  not  included  in  the  list. 


Table  1.  List  of  Stakeholders 


ID 

Stakeholder 

Sector 

1 

Department  of  Defense 

Government 

2 

NASA 

Government 

(Continued  on  next  page) 

26 


ID 

Stakeholder  (Continued  from  previous  page) 

Sector 

3 

U.S.  Air  Force 

Government 

4 

U.S.  Navy 

Government 

5 

U.S.  Army 

Government 

6 

U.S.  Marines 

Government 

7 

Air  Force  Space  Command 

Government 

8 

Naval  Space  Command 

Government 

9 

Army  Space  and  Missile  Defense  Command 

Government 

10 

Missile  Defense  Agency 

Government 

11 

National  Reconnaissance  Office 

Government 

12 

Central  Intelligence  Agency 

Government 

13 

Defense  Intelligence  Agency 

Government 

14 

National  Air  Space  Intelligence  Center 

Government 

15 

National  Security  Agency 

Government 

16 

National  Geospatial-Intelligence  Agency 

Government 

17 

Air  Force  Research  Lab 

Government 

18 

Space  &  Missile  Systems  Center 

Government 

19 

Space  Superiority  Systems  Directorate 

Government 

20 

Launch  Systems  Directorate 

Government 

21 

Military  Satellite  Communications 

Systems  Directorate 

Government 

22 

Global  Positioning  Systems  Directorate 

Government 

(Continued  on  next  page) 
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ID 

Stakeholder  (Continued  from  previous  page) 

Sector 

23 

Infrared  Space  Systems  Directorate 

Government 

24 

Space  Development  and  Test  Directorate 

Government 

25 

Defense  Weather  Systems  Directorate 

Government 

26 

Spacelift  Range  and  Network  Systems  Division 

Government 

27 

Lockheed  Martin 

Private 

28 

The  Boeing  Company 

Private 

29 

Northrop  Grumman  Corporation 

Private 

30 

Raytheon  Company 

Private 

31 

General  Dynamics  Corporation 

Private 

32 

Analytical  Graphics  Inc.  (AGI) 

Private 

33 

Assurance  Technology  Corporation 

Private 

34 

Orbital  Corporation 

Private 

35 

Other  defense  contractors 

Private 

36 

GPS  Users 

Public/Private/Gov 

37 

SATCOM  Users 

Public/Private/Gov 

38 

Television  Users 

Public/Private/Gov 

39 

Television  stations 

Private 

40 

Direct  TV 

Private 

41 

Dish  Network 

Private 

42 

SiriusXM  Satellite  Radio 

Private 

43 

Satellite  Radio  Users 

Public 

(Continued  on  next  page) 
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ID 

Stakeholder  (Continued  from  previous  page) 

Sector 

44 

Foreign  Allied  Governments 

Government 

45 

Joint  Space  Operations  Center 

Government 

46 

U.S.  Strategic  Command 

Government 

47 

United  Launch  Alliance 

Private 

48 

Congress 

Government 

49 

Air  Force  Operational  Test  &  Evaluation  Center 

(AFOTEC) 

Government 

50 

U.S.  Coast  Guard 

Government 

51 

Federal  Aviation  Administration 

Government 

The  stakeholders  listed  in  Table  1  represent  the  majority  of  groups  that  would  be 
involved  with  or  benefit  from  a  hosted  SSA  payload  architecture.  Some  of  the 
stakeholders  mentioned,  such  as  Congress  or  the  U.S.  Air  Force,  have  direct  impact  on 
funding  to  a  potential  program  and  thus  are  included  as  stakeholders.  The  various 
directorates,  defense  contractors  and  launch  organizations  mentioned  would  be  the 
primary  means  of  fielding  the  architecture.  Others,  such  as  AFOTEC,  may  contribute  to 
the  testing  and  operationalization  of  the  system.  The  users  mentioned  may  not  ever  know 
that  there  is  an  SSA  system  in  orbit  assuring  the  continued  use  of  various  services. 
However,  these  users  would  benefit  from  the  availability  of  systems  derived  from  SSA. 
Finally,  as  with  any  sensor  which  produces  data,  there  is  potential  intelligence  that  can  be 
gathered.  The  intelligence  organizations  are  included  as  stakeholders  due  to  the  large 
potential  for  intelligence  to  be  derived  from  SSA  data  collected. 

C.  FUNCTIONAL  ANALYSIS 

To  develop  architecture  for  a  hosted  payload  to  perform  an  SSA  mission,  there  are 

certain  requirements  the  system  must  meet  to  be  effective.  For  this  thesis,  research  was 

conducted  on  existing  systems.  NASA,  as  well  as  Air  Force  programs,  were  reviewed  to 
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gain  an  understanding  of  hosted  payloads,  and  a  set  of  generic  high  level  requirements 
were  developed  for  a  hosted  payload.  These  requirements  will  meet  the  needs  of  a  hosted 
SSA  payload  that  can  enable  a  larger  SSA  architecture  using  hosted  payloads.  While  not 
included  in  this  thesis,  an  area  of  further  study  includes  the  decomposition  of  the  high 
level  requirements  into  lower  level  requirements  and  captured  as  technical  requirements. 
In  acquisition  circles,  this  table  would  be  known  as  a  technical  requirements  document 
(TRD). 

Typically,  functional  analysis  is  first  employed  to  assist  in  performing  concept 
trades  and  is  often  a  major  systems  engineering  activity.  Additionally,  Functional 
analysis  is  used  to  help  yield  descriptions  of  actions  rather  than  a  parts  list  (Space  and 
Missile  Systems  Center  2005,  244).  To  begin  developing  requirements,  a  high  level 
functional  analysis  was  conducted  as  shown  in  Figure  8. 


Figure  8.  Functional  Decomposition 


The  top  level  function,  Function  0.0,  is  simply  stated  as  “Provide  SSA.”  This  top 
level  function  was  then  decomposed  into  four  lower  level  functions,  Functions  1.1  -  1.4. 
These  four  lower  level  functions  provide  the  basis  for  the  requirements  development  as 
well  as  the  STK  analysis  conducted  later  on  in  this  thesis. 
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Function  1.1  provides  for  SSA  in  the  nadir,  or  Earth  facing,  direction.  The 
function  is  critical  to  provide  SSA  against  threats  from  the  ground  such  as  ground 
launched  ASAT’s,  space  object  surveillance  and  identification  sites,  and  general  earth 
imaging. 

Function  1.2  provides  for  SSA  along  the  orbital  path.  Having  SSA  along  the 
orbital  path  fulfills  a  large  concern  for  satellite  operators,  knowing  if  there  is  something 
along  the  orbital  path.  This  function  will  allow  for  collision  avoidance  as  well  as 
detection  of  space  based  ASAT’s. 

Function  1.3  provides  for  communication  with  the  system.  Having  a  SSA  system 
on  a  satellite  is  not  useful  if  the  system  is  unable  to  communicate  with  the  operators  as 
well  as  receive  commands  from  the  operators. 

Finally,  Function  1.4  provides  a  means  to  process  collected  data  and  provide  it  to 
potential  users.  Without  this  functionality,  the  data  may  exist,  however,  there  would  be 
no  method  to  utilize  the  data. 

Due  to  the  academic  nature  of  this  project  as  well  as  the  availability  of  data  from 
the  SASSA  program,  further  functional  analysis  was  not  performed  for  this  thesis. 
However,  if  a  program  office  were  designing  this  system  for  operational  purposes,  versus 
an  academic  discussion,  then  a  much  more  in-depth  functional  analysis  would  need  to  be 
included  while  developing  requirements. 

D.  REQUIREMENTS  ANALYSIS 

To  develop  the  high  level  requirements,  the  program  level  requirements  from  the 
SASSA  program  were  leveraged  and  modified  into  the  generic  high  level  requirements  listed 
in  Table  2.  Some  of  the  requirements  developed  were  functional  requirements  while  others 
were  requirements  aimed  at  meeting  various  stakeholder  needs.  Functional  requirements  are 
shows  with  a  (F)  next  to  them.  The  requirements  are  coined  as  “generic”  due  to  the  fact  that 
they  have  not  been  adapted  to  any  particular  mission  and  are  meant  to  be  a  one  size  fits  all 
solution.  In  reality,  the  requirements  presented  in  Table  2  would  need  to  be  reviewed, 
modified  or  possibly  eliminated  depending  on  the  needs  of  the  actual  mission.  For  this  thesis 
however,  the  SASSA  requirements  were  the  best  example  of  requirements  found  during  the 
research,  and  were  chosen  due  to  the  close  aligmnent  with  the  goals  of  this  thesis.  The  high 
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level  requirements  set  provides  the  first  step  of  building  a  SSA  architecture  using  hosted 
payloads  by  providing  the  foundation  for  the  payloads  themselves. 


Table  2.  Generic  Hosted  Payload  Requirements 


Generic  Hosted  Payload  Requirements 

R1.0 

HP  SHALL  interface  with  multiple  common  spacecraft  busses 

Use  industry  standard/common  interfaces  for  electrical, 

hardware  and  data 

R2.0 

HP  SHALL  accept  integration  of  multiple  dissimilar  instruments 

Use  industry  standard/common  interfaces  for  electrical, 

hardware  and  data 

R3.0 

HP  SHALL  use  a  modular  and  scalable  software  architecture 

R4.0 

(F) 

HP  SHALL  use  high  TRL  threat  warning  instruments 

Proximity  sensor,  radar  warning  receiver  (RWR),  laser  warning 

receiver  (LWR),  environmental  sensor,  camera,  laser  range 

finder,  etc. 

R5.0 

HP  SHALL  output  all  sensor  information  in  an  machine  and  human 

readable  format 

R6.0 

HP  SHALL  meet  USAF  launch  vehicle  specifications 

R7.0 

HP  SHALL  not  interfere  with  host  vehicle  payload/bus  operations 

R8.0 

(F) 

HP  SHALL  be  capable  of  accepting  command  and  control  (C2)  inputs 

independent  of  host  vehicle 

R9.0 

(F) 

HP  SHALL  have  a  ground  segment  application  that  can  be  integrated 

into  the  host  ground  segment 

The  requirements  presented  in  Table  2  provide  a  high  level  requirement  set  that 
can  be  leveraged  by  a  government  program  office  to  provide  to  industry  to  build  a 
material  solution.  Rationale  for  each  requirement  is  provided  in  the  following  paragraphs. 

Requirement  1.0-  HP  SHALL  interface  with  multiple  common  spacecraft  busses 
-  provides  assurance  that  the  architecture  design  of  the  payload  is  expandable,  scalable 
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and  supportable.  By  taking  advantage  of  multiple  interfaces  and  using  industry  standards, 
the  architecture  is  assured  to  remain  open.  Interfaces  could  include  RS422,  1553,  space 
wire  or  Ethernet  connections  (Wertz  and  Larson  1991,  175).  Using  these  interfaces 
facilitate  the  easy  adoption  across  multiple  spacecraft.  Additionally,  this  requirement  is 
important  because  it  will  allow  the  “global”  SSA  discussed  earlier  in  the  thesis  to  be 
achievable.  Without  the  capability  to  adapt  to  varying  spacecraft,  the  hosted  SSA  payload 
would  not  be  able  to  be  used  on  multiple  spacecraft.  By  not  fulfilling  this  requirement, 
the  entire  architecture  would  be  negated.  To  verily  this  requirement,  inspection  would  be 
used  to  ensure  that  the  common  interfaces  exist  on  the  system. 

Requirement  2.0  -  HP  SHALL  accept  integration  of  multiple  dissimilar 
instruments  -  is  one  of  the  major  facilitators  for  a  “global”  SSA  system.  By  providing  the 
means  for  multiple  dissimilar  instruments  to  be  integrated  onto  the  hosted  payload 
system,  the  architecture  for  a  hosted  payload  SSA  will  be  usable  in  various  orbits  against 
varying  threats.  The  actual  number  of  dissimilar  instruments  would  depend  on  the  type  of 
SSA  desired,  and  could  range  from  two  instruments  to  as  many  as  the  system  was 
designed  to  support.  In  other  words,  if  a  potential  host  is  more  concerned  with  collisions 
than  with  the  threat  of  being  illuminated  by  lasers,  then  a  proximity-sensing  instrument 
could  be  used.  If  however  the  potential  host  was  an  optical  imaging  satellite,  laser  threats 
may  be  a  real  danger  and  require  laser-sensing  instruments.  The  main  point  of  this 
requirement  is  to  let  the  hosted  payload  be  instrument  agnostic  and  customizable  to 
provide  SSA  against  the  many  threats  in  space.  Verification  of  this  requirement  would  be 
by  inspection  and  test.  Visual  inspection  would  detennine  how  many  instruments  had 
been  physically  integrated  onto  the  system.  Testing  would  verily  the  instruments  actually 
work  once  integrated. 

Requirement  3.0  -  HP  SHALL  use  a  modular  and  scalable  software  architecture  - 
ensures  the  software  architecture  is  modular  and  tailorable.  “Software  architecture  is  the 
set  of  design  decisions  which,  if  made  incorrectly,  may  cause  your  project  to  be 
cancelled”  (Bass,  Clements  and  Kazman  2012,  25).  For  this  reason,  it  is  imperative  the 
software  architecture  is  designed  properly.  Modular  software  helps  eliminate  the  need  for 
complete  software  redesign  in  case  there  is  a  change  later  on  in  the  life  cycle.  Modular 
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software  is  a  software  design  technique  that  separates  various  parts  of  the  software  into 
individual  modules.  These  modules  are  combined  to  form  the  larger  software  application. 
By  using  modules,  if  a  software  change  is  required,  specific  modules  may  be  changed 
versus  changing  the  entire  software  application.  Tailorable  software  architecture  allows 
various  instruments  to  be  supported  as  mission  requirements  change  (Bass,  Clements  and 
Kazman  2012,  45).  Verification  of  this  requirement  consists  of  inspection  as  well  as  test. 
A  software  expert  could  ensure  the  software  is  modular  by  inspection,  in  the  form  of  a 
code  review.  Testing  would  be  required  to  ensure  the  software  can  be  modified  and  the 
software  would  continue  to  perform  as  designed. 

Requirement  4.0  -  HP  SHALL  use  high  TRL  threat  warning  instruments  - 
ensures  that  the  instruments  being  used  on  the  hosted  SSA  payload  are  at  a  high  enough 
technology  readiness  level  (TRL)  to  support  operational  missions.  This  would  mean  that 
the  instruments  would  be  at  TRL  8  or  TRL  9  (Space  and  Missile  Systems  Center  2005, 
261).  The  intent  of  this  requirement  is  to  ensure  the  instruments  being  integrated  into  the 
system  are  mature,  provide  low  risk  and  reliable  SSA  to  the  host  spacecraft.  Additionally, 
this  requirement  fulfills  Function  1.1  and  Function  1.2.  By  providing  the  high  TRL 
instruments,  the  two  directional  SSA  functions  can  be  fulfilled.  Verification  of  this 
requirement  would  need  to  be  perfonned  by  inspection  and  test.  Engineers  could  inspect 
documentation  to  ensure  the  TRL  of  the  instrument  has  met  the  level  of  testing  required. 
Additionally,  tests  could  be  perfonned  on  the  instruments  in  operationally  realistic 
environments  to  ensure  the  instruments  meet  the  TRL. 

Requirement  5.0  -  HP  SHALL  output  all  sensor  information  in  an  machine  and 
human  readable  format  -  is  levied  to  ensure  that  once  the  data  is  processed  on  board  the 
hosted  SSA  payload,  the  data  is  output  in  a  standard  format.  The  format  must  be  machine 
and  human  readable;  an  example  of  this  format  would  be  XML.  This  will  ensure  the  data 
is  net  ready  and  usable  by  multiple  users.  The  use  of  propriety  formats  would  not  be 
acceptable  to  fulfill  this  requirement.  The  output  fonnat  must  be  an  open  standard. 
Verification  for  the  requirement  would  be  perfonned  by  inspection  and  test.  An  engineer 
could  inspect  the  output  to  ensure  the  data  is  human  readable,  while  testing  could  be  used 
to  verify  the  data  is  machine  readable. 
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Requirement  6.0  -  HP  SHALL  meet  USAF  launch  vehicle  specifications  - 
ensures  that  when  the  hosted  SSA  payload  is  designed  and  fielded,  it  can  be  launched  on 
a  United  States  launch  vehicle.  An  example  of  a  U.S.  launch  vehicle  would  be  the 
Evolved  Expendable  Launch  Vehicle  (EELV).  The  reference  for  vehicle  specifications  is 
the  EELV  Standard  Interface  Specification  Version  6.0,  dated  5  September  2000.  (EELV 
Standard  Interface  Working  Group  2000).  Verification  for  this  requirement  would  be 
performed  by  simulation.  A  simulation  of  the  system  would  need  to  be  completed  to 
ensure  the  payload  is  able  to  launch  on  a  USAF  launch  vehicle  using  launch  modeling 
software. 

Requirement  7.0  -  HP  SHALL  not  interfere  with  host  vehicle  payload/bus 
operations  -  safeguards  the  vehicle  and  payloads  on  the  host  spacecraft  that  are  not  part 
of  the  hosted  SSA  payload.  Ensuring  the  SSA  payload  works  on  a  non-interference  basis 
will  help  adoption  of  the  hosted  payload,  as  well  as  ensure  other  critical  missions  are  not 
disrupted.  Simulation  and  testing  would  be  used  to  verify  this  requirement.  Simulations 
would  give  the  first  verification  that  the  system  does  not  interfere  with  the  host  vehicle 
operations.  Once  the  hosted  payload  was  integrated  onto  the  host  spacecraft,  additional 
testing  would  need  to  be  perfonned  to  verify  the  system  performs  as  designed  and  causes 
no  interference. 

Requirement  8.0  -  HP  SHALL  be  capable  of  accepting  command  and  control 
(C2)  inputs  independent  of  host  vehicle  -  allows  for  the  hosted  payload  to  be  commanded 
and  controlled  in  the  case  that  the  host  command  and  control  (C2)  path  is  not  available. 
Additionally,  having  an  independent  C2  path  will  provide  redundancy  and  increase  the 
reliability  of  the  system.  Furthermore,  this  requirement  fulfills  Functions  1.3  and  1.4.  By 
providing  C2  inputs,  the  communication  and  data  processing  functions  are  enabled.  For 
this  requirement,  simulation  and  testing  would  be  required  for  verification.  Simulations 
would  provide  the  first  level  of  verification  that  the  system  has  the  ability  to  be 
independently  commanded.  Once  the  hosted  payload  was  integrated  onto  the  host 
spacecraft,  additional  testing  would  need  to  be  performed  to  verify  the  system  performs 
as  designed.  Lastly,  for  this  requirement,  there  would  need  to  be  additional  testing  once 
the  system  was  launched  to  verify  the  requirement  was  met. 
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Finally,  Requirement  9.0  -  HP  SHALL  have  a  ground  segment  application  that 
can  be  integrated  into  the  host  ground  segment  -  provides  for  the  ground  segment  of  the 
hosted  payload  to  work  on  the  existing  host  ground  segment.  This  will  reduce  the  overall 
footprint  of  the  system,  provide  a  seamless  user  experience,  and  reduce  the  need  for 
multiple  ground  systems  to  be  fielded.  Additionally,  as  an  application  the  hosted  payload 
ground  segment  could  be  accessed  by  any  node,  versus  having  a  dedicated  node.  In  other 
words,  existing  computers  could  be  utilized  as  the  ground  system  instead  of  having  to 
field  separate  stand-alone  systems.  Furthermore,  this  requirement  fulfills  Functions  1.3 
and  1 .4  by  providing  a  means  for  operators  to  communicate  with  the  system  and  receive 
processed  data.  This  requirement  could  be  verified  by  inspection.  An  engineer  could 
verily  the  ground  segment  software  was  resident  on  the  existing  host  ground  segment 
visually. 

The  generic  requirements  developed  here  are  the  basis  of  developing  a  SSA 
architecture  utilizing  hosted  payloads,  and  will  be  utilized  in  the  next  part  of  this  thesis. 
The  next  step  for  this  thesis  will  be  to  conduct  modeling  and  simulation  using  STK  to 
determine  how  payloads  should  be  distributed  to  provide  worldwide  SSA  coverage.  In 
reality,  if  one  desired  to  pursue  developing  a  system  based  on  the  generic  requirements 
presented,  the  requirements  would  need  to  be  broken  down  into  the  detailed  technical 
requirements  before  pursuing  modeling  and  simulation.  However,  since  only  notional 
sensor  values  will  be  used  in  the  simulation,  further  breakdown  of  the  requirements  were 
not  necessary  for  this  thesis. 
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IV.  SYSTEMS  ARCHITECTURE  DESIGN 


A.  ARCHITECTURAL  DEVELOPMENT  OVERVIEW 

A  two-step  was  approach  taken  to  develop  the  SSA  architecture  utilizing  hosted 
payloads.  The  first  step  involved  developing  the  functions  and  requirements  for  a  hosted 
SSA  payload,  which  serves  as  the  basis  of  the  architecture.  The  second  step  involved 
conducting  analysis  via  simulations  in  STK  to  determine  how  a  notional  hosted  payloads 
system  would  be  fielded.  Ultimately,  the  simulations  provided  the  basis  for  developing 
the  final  OV-1  architecture  product. 

To  develop  a  simulation  to  fulfill  the  functions  and  requirements,  the  system 
modeled  in  STK  included  the  following  items  and  assumptions: 

•  Interface/processing  unit  to  integrate  sensors  onto  a  spacecraft 

o  This  interface  was  assumed  available  and  no  additional  modeling 
was  required 

•  One  nadir  facing  optical  sensor 

o  For  this  sensor,  it  was  assumed  that  the  maximum  Earth  coverage 
and  resolution  was  desired 

o  Modeling  was  conducted  to  fulfill  these  assumptions 

•  Two  optical  sensors  along  the  orbital  path,  facing  forward  and  aft 

o  For  these  sensors,  it  was  assumed  that  the  sensors  would  be 
detecting  debris  along  the  orbital  path 

o  Modeling  was  conducted  to  fulfill  this  assumption 

These  item  and  assumptions  were  chosen  as  a  notional  system  that  would  be  used 
on  a  LEO  satellite.  While  other  sensors  or  types  of  systems  could  have  been  used,  it  was 
determined  this  type  of  system  would  fulfill  needs  of  most  of  stakeholders.  This  is  due  to 
the  fact  that  most  of  the  stakeholders  would  be  concerned  with  collision  avoidance  as 
well  as  intelligence  gathering.  Having  the  assumed  system  provides  these  two  aspects  for 
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the  stakeholders  in  a  single  hosted  SSA  system,  and  meets  the  functions  laid  out  in  Figure 
8.  Additionally,  the  proposed  system  provides  a  sufficient  model  to  develop  the  OV-1. 

Optimal  parameters  were  found  for  the  three  notional  sensors.  Additionally, 
modeling  was  conducted  to  determine  how  many  payloads  would  be  required  to  cover  SSA 
over  an  entire  orbital  plane.  The  analysis  was  conducted  in  STK  with  the  understanding 
that  the  sensors  were  notional  and  not  representative  on  any  one  particular  sensor  available 
currently.  However,  since  only  a  single  orbital  plane  was  being  analyzed,  the  various 
parameters  of  the  constellation  were  optimized  to  ensure  SSA  could  be  maximized  even  in 
a  single  plane.  Finally,  once  these  two  steps  were  completed,  conclusions  about  the 
architecture  were  made  and  an  Operational  View  -  1  (OV-1)  was  developed. 

To  conduct  the  STK  analysis,  some  other  assumptions  were  needed  to  facilitate 
the  analysis  and  limit  computational  time  of  the  software.  Firstly,  the  hosted  payload 
could  be  placed  on  board  any  notional  spacecraft  orbiting  in  LEO.  Next,  it  was  assumed 
the  main  threats  to  the  satellite  would  be  from  the  following  sources:  1)  ground  based 
threats  such  as  space  object  surveillance  and  identification  (SOSI)  radar  and  optical  sites, 
2)  ground  based  laser  or  direct  assent  anti-satellite  (AS AT)  weapons,  3)  objects  along  the 
velocity  vector  (i.e.,  path  of  orbit)  such  as  debris  or  another  satellite  4)  object 
approaching  from  behind  in  the  orbit  (e.g.,  co-orbital  ASATs).  Additionally,  objects 
considered  threats  will  be  at  least  1  meter  in  diameter.  Using  these  assumptions,  the 
analysis  was  conducted  in  STK. 

B.  STK  ANALYSIS 

STK  is  a  physics-based  software  package  developed  by  Analytical  Graphics,  Inc.  It  is 
widely  used  in  the  space  systems  development  to  allow  engineers  and  scientists  to  perfonn 
complex  analysis  of  space  assets.  For  this  thesis,  the  following  modules  were  used  to  conduct 
the  analysis  and  would  be  required  to  recreate  any  of  the  analysis  discussed: 

•  Coverage  Module 

•  Electro-Optical  Infrared  Module 

•  Analyzer  Module 

•  Optimizer  Module 

•  Professional  Module 
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The  next  portion  of  this  thesis  walks  the  reader  through  a  step  by  step  process  on 
how  optimal  values  for  the  architecture  were  found  using  STK.  Using  a  top-down 
methodology,  STK  was  used  to  develop  the  notional  three-sensor  hosted  payload  SSA 
system.  First,  STK  was  used  to  determine  the  optimal  orbit  placement  for  the  SSA 
satellite  constellation  to  provide  the  greatest  coverage  of  the  Earth  as  possible.  This  was 
done  so  that  a  single  plane  of  satellites  with  nadir  (e.g.  Earth  facing)  sensors  could 
monitor  the  maximum  amount  of  ground  space  object  surveillance  and  identification 
sites.  Optimal  parameters  for  the  satellite’s  orbit  included  altitude,  inclination  and  right 
ascension  of  the  ascending  node  (RAAN). 

For  the  sensors,  the  first  sensor  modeled  provides  nadir- facing  coverage,  while 
the  second  and  third  sensors  provide  SSA  along  the  orbital  path,  forward  and  aft  (e.g., 
backwards).  For  the  purposes  of  this  thesis,  all  three  sensors  were  optical  sensors.  These 
were  chosen  due  to  the  modeling  capability  in  STK  as  well  as  security  purposes. 
Modeling  SIGINT  sensors,  such  as  an  RWR,  requires  higher  levels  of  security,  thus  were 
not  modeled.  Since  the  three  sensors  being  modeled  are  optical  sensors,  STK  was  used 
to  determine  optimal  focal  lengths,  pixel  pitch  (size)  and  resolution  of  the  sensors.  These 
parameters  are  the  main  characteristics  of  an  optical  system. 

Finally,  once  the  satellite  and  sensor’s  parameters  were  all  calculated  to  optimal 
values,  STK  was  used  to  populate  a  constellation  with  identical  satellites  in  a  single  plane 
to  determine  how  many  satellites  are  required  to  provide  coverage  around  the  entire  globe 
in  a  single  plane. 

The  following  list  provides  a  summary  of  what  was  done  in  STK: 

•  An  LEO  orbit  satellite  was  created 

•  A  GEO  orbit  relay  satellite  was  created  to  send  data  down  to  a  selected 
point  on  earth;  in  this  case  Monterey,  CA 

•  A  nadir  or  earthward  facing  sensor  was  created 

•  Optimum  parameters  for  the  nadir  sensor  were  calculated  by  starting  at  a 
broad  range  and  narrowing  the  parameters  down  to  the  optimal  value 
using  multi-step  simulations 

•  Parameters  for  the  nadir  sensor  include  focal  length,  pixel  pitch 
(size)  and  resolution 

•  Once  sensor  parameters  for  the  nadir  sensor  were  created,  the  forward  and 
aft  facing  sensor  parameters  were  analyzed  in  a  similar  fashion 

39 


•  Parameters  for  the  forward  and  aft  sensors  include  focal  length, 
pixel  pitch  and  resolution 

•  Once  sensor  parameter  calculations  were  completed,  the  number  of 
satellites  required  to  provide  global  coverage  in  a  single  plane  was 
determined. 

Screen  shots  are  provided  for  each  major  step  to  demonstrate  what  process  or  menu  was 
used,  or  to  show  what  the  output  for  a  certain  process  was  in  order  to  allow  others  to 
recreate  the  results. 

To  start  the  analysis,  an  orbit  was  specified  in  STK.  For  the  case  of  this  thesis,  a 
notional  LEO  orbit  was  selected  as  seen  in  Figure  9.  Monterey,  CA  was  selected  as  the 
notional  ground  site,  and  a  notional  relay  satellite  was  created  to  pass  data  from  LEO 
orbit  to  the  ground  station.  In  STK,  the  user  has  to  specify  an  area  of  interest.  The  areas 
of  interest  are  the  points  on  the  earth  that  a  satellite  must  monitor.  In  other  words,  the 
locations  the  nadir  facing  sensor  will  monitor.  In  the  case  of  this  thesis,  the  area  of 
interest  was  based  on  the  location  of  land  mass  and  commercial  shipping  routes.  It  was 
assumed  that  monitoring  the  polar  regions  was  a  lower  priority  since  the  analysis  being 
done  is  for  the  optimal  plane. 


Figure  9.  Selection  of  LEO  Orbit  in  STK 
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Once  the  orbit  was  selected,  the  star  background  was  removed  to  minimize 
processing  needed  as  shown  in  Figure  10.  To  do  this,  the  3D  Graphics  window  is  opened 
and  the  Show  in  the  Celestial  option  is  deselected.  This  is  mainly  done  to  minimize 
processing  time  for  the  simulations.  If  desired,  the  celestial  background  can  be 
reintroduced  at  a  later  point  in  time. 


Figure  10.  Remove  Star  Background  in  STK 
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After  removing  the  star  background  in  STK,  the  various  components  that  have 
been  created  must  be  linked  together  so  they  will  work  together  in  the  simulation.  In  this 
case,  the  linked  components  include  a  satellite  with  sensors  in  LEO  orbit,  a 
communication  relay  satellite  in  GEO  orbit  and  a  ground  station  in  Monterey,  CA.  In 
order  to  create  the  linking,  a  Chain  must  be  created  by  simply  moving  Available  Objects 
to  the  Assigned  list.  The  sequence  of  the  list  will  determine  the  success  of  the  Chain. 
Once  the  Chain  is  created,  the  user  run  the  Access  function  in  STK  to  finalize  the  Chain, 
and  allows  relaying  back  to  Monterey.  This  step  is  shown  in  Figure  11. 


Figure  1 1 .  Creation  of  Chain  in  STK 
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Once  the  star  background  had  been  removed  and  a  chain  created,  a  coverage  area 
was  defined  as  depicted  in  Figure  12.  Defining  the  coverage  area  takes  the  area  of  interest 
a  step  further  by  giving  the  user  a  visual  representation  of  where  the  nadir  sensor  will  be 
able  to  see.  Additionally,  the  coverage  area  is  represented  in  various  colors,  which 
represent  how  many  times  a  particular  area  will  be  revisited  in  a  24-hour  orbit  by  a  single 
satellite.  This  step  requires  the  use  of  the  Coverage  module.  For  this  thesis,  the  Coverage 
is  defined  by  creating  the  Grid  Region  of  Interest,  and  the  latitude  is  bounded  from  -38° 
to  62°.  These  latitudes  were  selected  since  most  land  mass  and  shipping  lanes  lie  within 
them  (Wertz  and  Larson  1991,  213).  Additionally,  for  STK,  Point  Granularity  must  be 
defined  in  this  step.  This  is  due  to  the  fact  that  as  the  points  converge  during  the 
simulation,  the  model  fidelity  increases,  and  so  does  simulation  time.  For  this  thesis,  3° 
granularity  was  selected  since  the  nadir  sensor  will  have  a  large  field  of  view  (FOV),  and 
keeps  the  simulation  times  to  a  reasonable  length.  Note:  if  the  sensor  had  a  smaller  FOV, 
one  would  decrease  granularity  accordingly  to  avoid  significant  miscalculation. 


Figure  12.  Define  Coverage  Area 
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After  defining  the  coverage  area,  the  nadir  facing  sensor  was  assigned  to  the  system 
as  shown  in  Figure  13. 


Figure  13.  Assign  Sensor 
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Once  the  sensors  were  assigned,  a  figure  of  merit  (FOM)  was  defined  as  shown  in 
Figure  14.  A  FOM  lets  the  user  define  what  type  of  coverage  is  desired  from  the  sensor. 
Since  this  thesis  is  trying  to  provide  sensor  coverage  to  certain  points  on  the  Earth 
between  latitudes,  the  FOM  type  was  defined  to  be  Number  of  Accesses. 


Figure  14.  Define  Figure  of  Merit  (FOM) 
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After  defining  the  FOM,  the  coverage  was  computed  by  selecting  the  menu 
shown  in  Figure  15.  This  was  the  first  actual  simulation  run  in  STK,  and  the  computation 
took  approximately  five  minutes  to  execute.  The  computation  was  to  determine  the 
various  orbits  in  which  the  notional  satellite  could  be  placed  and  how  many  revisits  were 
possible  by  a  single  satellite. 


Figure  15.  Run  Coverage 
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After  running  coverage,  a  legend  was  made  as  shown  in  Figure  16.  This  was  done 
to  provide  a  key  to  differentiate  what  each  color  represents  on  the  globe  in  Figure  17. 


Figure  16.  Legend 
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Once  the  legend  was  made,  the  coverage  was  completed  as  shown  in  Figure  17. 
The  coverage  shown  represents  the  areas  the  Nadir  facing  sensor  will  be  able  to  see  while 
in  the  orbital  plane  and  number  of  revisits  to  the  particular  site  in  a  24  hour  period. 


^  3D  Graphics  1  -  Earth 
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Figure  17.  Completed  Coverage 
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Once  the  coverage  simulation  was  completed,  the  next  step  was  to  exploit  the 
analyzer  module  to  determine  an  ideal  orbit  for  the  SSA  mission  using  hosted  payloads. 
The  setup  of  this  is  shown  in  Figure  18. 
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Figure  18.  Analyzer  Setup 
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Once  the  analyzer  was  configured  in  general,  the  Parametric  Study  Tool  is  used  to 
first  determine  what  optimal  inclination  of  the  orbit  would  be  as  shown  in  Figure  19. 


Figure  19.  Select  Parametric  Study  Tool 
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After  the  Parametric  Study  Tool  is  selected,  the  Parametric  Study  menu  pops  up 
as  shown  in  Figure  20.  This  is  where  the  constraints  of  the  Design  Variables  are  defined. 
For  the  purposes  of  the  nadir  facing  sensor,  the  input  variable  was  inclination.  The  output 
values  were  minimum,  maximum  and  average.  It  should  also  be  noted  that  the  number  of 
samples,  in  this  case  10,  is  extremely  important.  This  directly  affects  the  step  size  and  can 
change  the  simulation  times  exponentially.  For  a  sample  size  of  10,  the  simulation  times 
were  ~10  minutes  for  each  run.  Also,  it  is  important  that  the  analysis  period,  in  this  case  7 
days,  is  setup  correctly  to  avoid  lengthy  simulation  times  or  potential  computer  crashes 
due  to  the  machine  running  for  days  on  end. 


Figure  20.  Parametric  Study  Tool  Menu 
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When  the  Parametric  Study  Tool  menu  appears,  the  Design  Variables  can  be  set. 
For  this  thesis  a  broad  range,  60°  to  120°  for  inclination  are  used  as  starting  and  ending 
values,  respectively,  for  inclination.  One  the  Design  Variables  are  set  as  shown  in  Figure 
2 1 ,  the  scenario  for  inclination  can  be  executed  by  selecting  Run. 


Figure  2 1 .  Set  Broad  Range  for  Inclination 
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It  should  be  noted  before  reviewing  the  following  data  that  in  all  of  the  following 
line  plots,  the  blue  line  represents  minimum  values,  the  red  line  represents  average  values 
and  the  green  line  represents  maximum  values.  Additionally,  STK  does  not  allow  for  the 
Y-axis  to  be  labeled  by  the  user,  and  places  the  default  label  of 
Minimum. Average. Maximum  instead.  In  reality,  the  Y-axis  represents  the  number  of 
areas  within  the  given  latitudes  the  satellite  will  be  able  to  fly  over  in  a  24-hour  period 
(e.g.,  number  of  revisits)  in  all  of  the  following  line  plots.  An  example  figure  is  shown  in 
FigureX  with  labels  to  help  the  reader  understand  the  plots  in  the  remainder  of  the  thesis. 


Figure  22.  Example  Plot 
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After  the  scenario  is  run,  an  output  of  inclinations  vs.  coverage  possible  was 
produced  as  shown  in  Figure  23.  By  looking  at  the  plot  for  the  maximum  line,  it  can  be 
seen  that  at  115°  or  greater,  the  number  of  areas  covered  reaches  a  plateau  of  35  revisits. 
Thus,  the  inclination  to  be  used  for  the  remainder  of  the  study  will  be  115°. 


Figure  23.  Output  for  Optimal  Inclination 


The  next  step  is  to  determine  the  optimal  value  for  the  Right  Ascension  of 
Ascending  Node  (RAAN)  and  re-run  the  scenario  to  see  if  RAAN  affects  coverage  as 
shown  in  Figure  24.  The  Design  Variables  are  once  again  set  up  to  encompass  a  broad 
range  of  values,  in  this  case  0°  to  360°.  The  number  of  samples  remains  at  ten  and  the 
step  size  is  adjusted  to  40  to  accommodate  the  wider  range  of  values.  Once  the  Design 
Variables  for  RAAN  are  set,  the  Run  option  is  selected  to  run  the  simulation. 
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Figure  24.  Set  Broad  Range  for  RAAN 


55 


When  the  scenario  is  re-run  for  broad  range  RAAN,  an  output  is  received.  From 
the  output  depicted  in  Figure  25,  it  can  be  see  that  the  uniform  region  of  interest  means 
RAAN  variances  have  little  effect  on  coverage.  Note  that  if  the  region  of  interest  had 
been  constrained  by  a  minimum  and  maximum  longitude,  then  there  would  have  been 
variance  in  the  RAAN.  What  can  be  inferred  from  the  output  is  that  RAAN  is  not  a  factor 
that  will  contribute  to  optimizing  the  system. 


RAAN  (deg) 


Figure  25.  Optimal  Output  for  RAAN 
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Once  the  optimal  inclination  and  RAAN  have  been  determined,  in  this  case  115° 
and  0°  respectively,  the  next  step  is  to  determine  the  semi-major  axis.  The  semi-major 
axis  is  what  defines  the  altitude  of  the  orbit  and  is  measured  from  the  center  of  the  Earth 
to  the  point  in  space  where  the  orbit  is.  There  are  typically  two  measurements  for  an 
orbit,  the  semi-major  axis  and  semi-minor  axis,  however  since  the  notional  LEO  orbit 
being  investigated  in  this  thesis  is  a  near  circular  orbit,  the  semi-minor  axis  does  not  need 
to  be  determined.  Figure  26  demonstrates  the  semi-major  and  semi-minor  axes.  Figure 
27  shows  the  setup  in  STK  to  detennine  the  semi-major  axis.  It  should  be  noted  that  the 
distance  from  center  of  Earth  to  surface  at  equator  is  6378km  (Wertz  and  Larson  1991, 
118).  When  the  outputs  for  the  semi-major  axis  are  presented,  the  distance  from  the 
center  of  the  Earth  to  the  equator  should  be  subtracted  form  the  distance  of  the  semi¬ 
major  axis  to  find  the  altitude  of  the  orbit  in  kilometers. 


Figure  26.  Semi-major  vs.  Semi-minor  Axis 
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Figure  27.  Set  Broad  Range  for  Semi-major  Axis 
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Once  the  broad  range  for  semi-major  axis  is  set,  in  this  case  a  starting  value  of 
6500km  and  the  ending  value  of  8000km,  the  scenario  is  rerun  and  the  output  is  exhibited 
in  Figure  28.  As  it  can  be  seen,  as  space  vehicle  altitude  increases,  ground  coverage 
increases  at  a  linear  rate.  This  is  expected  as  no  sensor  parameters  or  target  sizes  have 
been  considered  yet  also  due  to  this  fact,  there  is  no  optimal  point  in  Figure  28.  The 
biggest  takeaway  from  this  figure  is  that  as  altitude  increases,  the  number  of  revisits 
increases  as  well. 


»  lUwnum  ♦  Avenge 


Figure  28.  Output  of  Broad  Range  for  Semi-major  Axis 


Now  that  it  has  been  shown  that  coverage  will  increase  as  altitude  increases  in 
general,  the  nadir  sensor  parameters  must  be  adjusted  to  determine  the  how  sensor 
characteristics  affect  the  semi-major  axis.  Until  this  point,  Design  Variables  for 
inclination,  RAAN  and  semi-major  axis  were  adjusted  to  find  optimal  outputs.  The  sensor 
parameters  under  the  Passive  Earth  menu  were  not  adjusted.  The  sensor  parameters  for 
the  optical  sensors  include  Detector  Pitch  (e.g.,  pixel  size),  Focal  Length  and  Cone 
Angle. 
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Detector  Pitch  determines  how  large  each  pixel  on  the  optical  sensor  is.  An 
example  of  large  vs.  small  detector  pitch  is  shown  in  Figure  29,  where  each  inner  square 
represents  a  pixel.  As  the  pixel  size  shrinks,  it  can  be  seen  that  more  pixels  can  fit  on  the 
sensor,  yielding  a  better  image. 


Small  Detector  Pitch  Large  Detector  Pitch 

Figure  29.  Small  vs.  Large  Detector  Pitch 

Focal  length  in  an  optical  system  is  the  measure  of  how  strongly  the  system  can 
converge  or  diverge  light.  In  the  case  of  space  optical  systems,  such  as  ones  in  this  thesis, 
the  subject  (e.g.,  the  Earth  or  debris)  is  considered  far  away.  Due  to  this  fact,  a  longer 
focal  length  and  narrower  view  angle  or  cone  angle  is  required  to  provide  sufficient 
magnification.  Cone  angle  refers  to  the  imaginary  cone  created  from  the  front  of  the 
sensor  to  the  field  of  view  on  the  Earth.  An  example  of  cone  angle  is  shown  in  Figure  30. 


Figure  30.  Cone  Angle 
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Finally,  resolution  is  referred  to  in  this  thesis  as  well.  Resolution  is  affected  by 
detector  pitch  and  focal  length  and  refers  to  the  ability  to  detect  an  object  of  a  certain  size 
in  an  image.  For  example,  a  2-meter  resolution  image  would  allow  two  objects  2-meters 
in  size  to  be  differentiated  in  an  image.  (Wertz  and  Larson  1991,  180) 

The  values  for  detector  pitch,  focal  length  and  cone  angle  were  adjusted  using 
STK  to  find  the  optimal  sensor  parameters  vs.  semi-major  axis.  These  values  remained  at 
the  default  STK  values  of  Detector  Pitch  =0.0005,  Focal  Length  =  100m  and  Cone  Angle 
=  55  as  shown  in  Figure  3 1  while  the  orbital  parameters  were  being  determined. 


Figure  3 1 .  Passive  Earth  Values  Held  Steady 


To  develop  a  general  understanding  for  how  a  nadir  sensor  will  affect  the  semi¬ 
major  axis,  a  very  broad  range  of  sensor  parameters  were  used.  Resolution  was 
constrained  to  5m,  meaning  an  object  5m  in  size  on  the  surface  of  the  Earth  can  be 
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differentiated  from  another  5m  object  on  the  Earth.  Also,  the  focal  length  was  set  to 
100m.  In  reality,  a  100m  focal  length  would  require  a  very  large  aperture  (e.g.,  lens)  on 
the  sensor,  and  would  not  be  feasible  for  a  hosted  payload.  However,  the  focal  length  was 
chosen  so  a  starting  point  could  be  established  as  shown  in  Figure  32.  Looking  at  Figure 
32,  it  can  be  seen  that  as  altitude  increases,  ground  coverage  increases  at  a  non-linear 
rate,  until  it  reaches  a  peak.  This  peak  on  the  green  line,  at  approximately  6945km,  would 
be  the  optimum  point  if  a  100m  aperture  was  used.  Another  item  to  note  is  the  large 
trough  in  the  blue  line  at  the  optimum  point.  Upon  investigation,  it  was  discovered  that 
this  was  attributed  to  the  number  of  samples  taken.  If  simulation  time  had  been  increased, 
the  trough  would  have  not  been  shown.  In  this  case  though,  the  simulation  took 
approximately  10  minutes,  and  it  was  determined  that  a  second  simulation  was 
unnecessary  for  the  unrealistic  aperture  size. 


Figure  32.  Output  of  Semi-Major  Axis  with  Nadir  Sensor  Constrained  to  5m 

Resolution,  100m  Focal  Length 
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To  continue  the  analysis  in  finding  the  optimum  semi-major  axis,  other  focal 
lengths  were  considered  as  well.  In  Figure  33,  the  focal  length  is  set  to  50m  while  holding 
other  factors  steady. 


SemiMajorAxis  (km) 


Figure  33.  Output  of  Semi-Major  Axis  with  Nadir  Sensor  Constrained  to  5m 

Resolution,  50m  Focal  Length 

By  adjusting  the  focal  length  to  50m,  the  optimal  semi-major  axis  has  shifted  to  a 
lower  altitude  of  6610km  on  the  green  line.  This  altitude  is  only  about  300km  above  the 
surface  of  the  Earth  and  not  a  very  usable  orbit.  In  addition,  50m  for  focal  length  is  still  a 
large  value  for  a  hosted  payload.  In  the  next  scenario,  the  focal  length  is  adjusted  to  25m. 
This  is  shown  in  Figure  34. 
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Figure  34.  Output  of  Semi-Major  Axis  with  Nadir  Sensor  Constrained  to  5m 

Resolution,  25m  Focal  Length 

It  can  be  seen  that  with  the  smaller  focal  length,  the  orbit  is  now  starting  to  shift 
towards  a  more  usable  altitude.  In  this  case  the  optimal  point  on  the  green  line  lies  at 
7340km.  In  the  next  scenario,  focal  length  was  adjusted  to  10m.  In  addition,  the  pixel 
pitch,  which  is  the  size  of  the  pixels  on  the  sensor,  was  adjusted  to  5  *  10~6m  vs. 
5  *  10_5m.  The  output  is  shown  in  Figure  35. 
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Figure  35.  Output  of  Semi-Major  Axis  with  Nadir  Sensor  Constrained  to  5  *  10  6m 

Pixel  Pitch  and  10m  Focal  Length 


The  output  for  this  scenario  places  the  optimal  point  for  the  semi-major  axis  at 
approximately  8850km.  After  this  point,  there  is  degradation  in  system  performance  as 
can  be  seen  by  the  decay  of  the  green  line.  While  these  results  are  beginning  to  look 
promising,  it  should  be  noted  that  since  a  10m  aperture  is  still  a  very  large  size,  requiring 
a  very  large  lens,  the  results  here  are  still  not  optimal  for  the  purposes  of  a  hosted 
payload. 
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In  the  next  scenario,  focal  length  was  set  to  lm  and  pixel  pitch  was  set  to  5  * 
lCn7m.  The  results  are  depicted  in  Figure  36. 


Figure  36.  Output  of  Semi-Major  Axis  with  Nadir  Sensor  Constrained  to  5  *  10  7m 

Pixel  Pitch  and  lm  Focal  Length 


This  scenario  presented  an  interesting  result.  Although  the  focal  length  was 
decreased  by  9  meters,  by  decreasing  the  pixel  pitch  by  an  order  of  magnitude  the  net 
result  was  exactly  the  same  curve  as  the  previous  scenario  depicted  in  Figure  35.  This  is 
good  to  see  since  it  shows  that  similar  performance  from  a  sensor  can  be  achieved  by 
adjusting  pixel  pitch  while  making  the  focal  length  more  realistic  for  a  hosted  payload. 
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For  the  next  scenario,  the  focal  length  was  held  to  lm  and  pixel  pitch  was  held  to 
5  *  10_7m.  However,  the  resolution  of  the  sensor  was  adjusted  from  5m  to  lm,  meaning 
that  a  lm  object  on  the  ground  could  be  differentiated  from  another  lm  object.  The 
results  of  this  scenario  are  shown  in  Figure  37. 
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Figure  37.  Output  of  Semi-Major  Axis  with  Nadir  Sensor  Constrained  to  5  *  10  7m 
Pixel  Pitch,  lm  Focal  Length  and  lm  Resolution 

By  holding  the  focal  length  and  introducing  the  new  resolution  into  the  scenario, 
there  is  a  decrease  in  performance  as  far  as  number  of  times  a  particular  point  on  Earth  is 
seen  (e.g.,  the  Y-axis).  However,  the  performance  is  not  poor;  on  the  contrary  the  sensor 
performance  is  adequate  for  a  hosted  payload.  From  the  green  line,  it  can  be  seen  that  the 
performance  for  a  sensor  this  size  will  provide  26  revisits  at  the  optimal  point  of  7275km. 
In  addition,  7275km  is  in  the  usable  range  semi-major  axis  of  LEO  orbits  and  will 
provide  optimal  coverage  of  the  Earth. 
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In  the  next  scenario,  focal  length  was  set  to  0.5m  and  pixel  pitch  was  held  at 
5  *  10~7m  to  see  if  decreasing  focal  length  affects  the  semi-major  axis  any  further.  The 
results  are  shown  in  Figure  38. 


Figure  38.  Output  for  Semi-major  Axis,  Constrained  to  lm  Resolution,  0.5m  Focal 

Length,  5  *  10~7m  Pixel  Pitch 


By  shrinking  the  focal  length  and  holding  to  the  new  resolution  in  the  scenario, 
there  is  an  increase  in  performance  as  far  as  number  of  times  a  particular  point  on  Earth  is 
seen  (e.g.,  the  Y-axis).  From  the  green  line,  it  can  be  seen  that  the  performance  for  a 
sensor  this  size  will  provide  42  revisits  at  the  optimal  point  of  7275km.  It  is  important  to 
note  that  the  7275km  did  not  change  from  the  previous  scenario  to  this  scenario  being  the 
optimal  point.  This  means  that  the  simulations  have  found  the  optimal  distance  for  the 
semi-major  axis  at  7275.  For  the  purposes  of  this  thesis,  the  lm  focal  length  will  be  used 
as  a  baseline  in  the  remainder  of  the  analysis,  with  adjustments  made  as  necessary  to 
facilitate  the  analysis. 
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Since  each  simulation  up  to  this  point  has  taken  upwards  of  30  minutes  to  run,  this 
researcher  concluded  that  additional  runs  for  finding  the  optimal  semi-major  axis  were 
not  required  for  academic  purposes.  However,  the  author  of  this  thesis  was  interested  to 
see  what  the  results  would  be  if  no  constraint  were  placed  on  resolution,  meaning  the 
sensor  could  see  everything  from  space  as  if  it  there  were  no  distortion.  The  thought  was 
that  if  sensor  resolution  were  not  a  concern,  performance  would  increase.  To  test  this 
scenario,  one  final  run  was  done  with  results  shown  in  Figure  39. 
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Figure  39.  Output  for  Semi-major  Axis,  No  Resolution  Constraint,  0.5m  Focal 

Length,  5  *  10“7m  Pixel  Pitch 

By  looking  at  the  results  in  Figure  39,  it  can  be  seen  that  there  is  better  sensor 
performance,  but  only  slightly.  This  goes  to  show  that  having  infinite  capability,  such  as 
unlimited  resolution,  will  not  necessarily  provide  infinitely  better  results. 
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Once  various  outputs  for  semi-major  axis  were  analyzed  by  adjusting  for  various 
parameters  and  a  semi-major  axis  of  7275km  was  determined  to  be  the  optimal  point,  the 
next  step  was  to  see  how  inclination  would  affect  the  results.  Until  this  point,  the 
variables  of  inclination,  semi-major  axis,  and  RAAN  have  all  been  evaluated 
independently.  At  this  point,  they  will  be  evaluated  against  each  other  to  see  if  changing 
sensor  parameters  against  two  orbital  parameters  has  a  significant  effect  on  which  type  of 
nadir  sensor  to  specify.  To  begin  this  section  of  the  analysis,  a  carpet  plot  was  generated 
by  performing  a  2-dimensional  parametric  study  of  inclination  vs.  semi  major  axis.  The 
sensor  parameters  were  held  to  what  was  shown  in  Figure  39. 
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Figure  40.  3-Dimensional  Plot  of  2-Dimensional  Parametric  Study  for  Inclination  vs. 
Semi-major  Axis  with  No  Resolution  Constraint,  5  *  10_7m  Pixel  Pitch  and  lm  Focal 

Length 


While  it  is  difficult  to  ascertain  without  an  ability  to  zoom  in  on  the  image,  the 
reader  should  understand  that  in  Figure  40,  the  plot  shows  the  inclination  on  the  X-axis, 
number  of  revisits  on  the  Y-axis  and  distance  for  the  semi-major  axis  on  the  Z-axis.  If 
one  zooms  in  on  a  computer,  it  can  be  seen  that  the  optimal  point  (top  right  red  corner  of 
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the  plot)  lies  at  X=130°,  Y=22,  Z=7275km.  This  means  that  when  the  two  variables  are 
evaluated  against  each  other,  with  sensor  parameters  factored  in,  the  optimal  point  for 
inclination  actually  shifts  by  15°  from  115°  to  130°,  and  the  number  of  revisits  changes. 
The  number  of  revisits  does  not  affect  the  study  very  much,  however,  the  change  in 
inclination  will. 

To  see  if  adjusting  focal  length  and  adding  the  resolution  constraint  back  in  has 
any  affect  when  evaluating  inclination  vs.  semi-major  axis,  the  next  carpet  plot  is 
generated  with  a  focal  length  of  lm,  pixel  pitch  of  5  *  10_7m  and  a  lm  resolution 
constraint.  The  results  are  shown  in  Figure  41. 
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Figure  4 1 .  3-Dimensional  Plot  of  2-Dimensional  Parametric  Study  for  Inclination  vs. 

Semi-major  Axis  with  lm  Resolution  Constraint,  5  *  lCP7m  Pixel  Pitch  and  lm  Focal 

Length 

By  introducing  the  resolution  constraint  back  into  the  simulation  and  increasing 
the  focal  length,  the  optimal  point  now  has  shifted  a  bit.  The  optimal  point  now  lies  at 
X=133°,  Y=19  and  Z=7390km.  If  the  vertex  of  the  carpet  plot  in  Figure  41  is  shifted  to 
the  center,  then  one  can  better  visualize  the  data.  This  is  what  is  depicted  in  Figure  42. 
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Figure  42.  3-Dimensional  Plot  of  2-Dimensional  Parametric  Study  for  Inclination  vs. 
Semi-major  Axis  with  lm  Resolution  Constraint,  5  *  10_7m  Pixel  Pitch,  lm  Focal 

Length  and  Vertex  Centered 


By  centering  the  vertex,  the  decay  in  performance  as  the  Z  axis  increases  can  be 
better  seen,  however,  to  further  refine  the  data,  the  lower  bound  for  inclination  (X-axis) 
was  set  to  120°.  This  resulted  in  what  is  shown  in  Figure  43. 
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Figure  43.  3-Dimensional  Plot  of  2-Dimensional  Parametric  Study  for  Inclination  vs. 
Semi-major  Axis  with  lm  Resolution  Constraint,  5  *  10_7m  Pixel  Pitch,  lm  Focal 
Length,  Vertex  Centered  and  X-axis  Lower  Bound  Set  to  120° 


Running  the  scenario  again  with  the  data  further  confined,  the  final  optimal 
parameters  resulted  in  135°  inclination  and  the  semi-major  axis  changing  to  7275km. 
This  was  a  direct  result  of  a  smaller  subset  of  data  being  evaluated. 
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For  the  remainder  of  the  analysis,  these  values  will  be  used  for  inclination  and 
semi-major  axis  unless  it  was  necessary  to  change  them  for  the  analysis.  To  better  give 
the  reader  an  understanding  of  the  final  data,  a  contour  plot  was  generated,  which  is 
easier  to  read  in  a  printout.  This  is  shown  in  Figure  44. 
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Figure  44.  Contour  of  2-Dimensional  Parametric  Study  for  Inclination  vs.  Semi¬ 
major  Axis  with  lm  Resolution  Constraint,  5  *  10~7m  Pixel  Pitch,  lm  Focal  Length, 
Vertex  Centered  and  X-axis  Lower  Bound  Set  to  120° 


Looking  at  the  contour  plot,  the  reader  can  better  see  the  red  line  where  the 
optimal  point  lies. 


74 


For  the  next  part  of  the  simulations,  the  optimal  pixel  size  was  investigated.  Once 
again,  the  parametric  study  tool  was  used  as  shown  in  Figure  45. 
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Figure  45.  Parametric  Study  Menu  for  Optimal  Pixel  Size 


The 
and  ending 


design  variables  for  pixel  pitch,  or  DetectorPitch  in  STK,  are  given  a  starting 
value  as  shown,  1  *  1CT7  and  1  *  10~6,  respectively. 
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Once  the  scenario  is  setup,  it  is  run  to  output  the  optimal  pixel  size.  The  results 
can  be  seen  in  Figure  46. 


Figure  46.  Optimal  Pixel  Pitch  Plot 


As  one  can  see  from  Figure  46,  pixel  pitch  has  a  maximum  threshold  value,  which 
if  exceeded  will  result  in  degrade  coverage  capabilities.  In  this  case,  the  value  at  which 
degradation  begins  to  occur  is  at  5  *  10_7m. 
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Another  way  to  look  at  the  data  is  presented  in  Figure  47,  which  shows  the  data 
charted  onto  a  bar  graph.  For  the  sake  of  keeping  simulation  times  down,  only  ten 
intervals  were  run.  This  has  an  effect  on  precision,  as  seen  by  the  value  of  4.1  *  10_7m  in 
Figure  47  instead  of  5  *  10_7m  that  is  seen  in  Figure  46.  For  the  sake  of  this  thesis,  the 
results  from  Figure  46  will  be  used;  making  the  optimal  pixel  pitch  to  5  *  10_7m. 


E 

E 


1*007  2*007  3*007  4*007  S*007  6,-007  7e-007  8*007  9*007  1*008 


DetectorPItch  (m) 


Figure  47.  Bar  Graph  for  Optimal  Pixel  Pitch 
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The  next  step  in  the  study  is  to  investigate  optimal  focal  length.  Again,  the  parametric 
study  tool  is  employed  as  shown  in  Figure  48. 
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Figure  48.  Parametric  Study  Menu  for  Optimal  Focal  Length 


The  design  variables  for  Optimal  Focal  Length  are  given  a  starting  value  of  0.2  and 
ending  value  of  1.4. 
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Once  the  Design  Variables  for  focal  length  are  configured  and  the  scenario  run,  it 
can  be  seen  that  focal  length,  just  like  pixel  pitch,  has  a  threshold  value  that  when 
reached,  does  not  improve  coverage  capabilities.  The  output  of  the  scenario  is  shown 
Figure  49. 
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Figure  49.  Optimal  Focal  Length  Plot 
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The  next  step  in  the  study  was  to  run  the  two  previous  variables  against  each  other 
and  generate  a  carpet  plot  for  focal  length  vs.  pixel  pitch.  This  was  done  to  once  again 
ensure  that  one  variable  does  not  affect  the  other.  The  results  are  shown  in  Figure  50. 
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Figure  50.  3 -Dimensional  Plot  of  2-Dimensional  Parametric  Study  for  Pixel  Pitch  vs. 

Focal  Length 

The  carpet  plot  shows  there  is  significant  interaction  between  pixel  pitch  and  focal 
length.  The  plot  shows  the  focal  length  on  the  X-axis,  number  of  revisits  on  the  Y-axis 
and  pixel  pitch  on  the  Z-axis.  Again,  the  plot  may  be  difficult  to  visualize  if  not  viewing 
on  in  an  electronic  format,  so  a  contour  plot  was  also  created.  This  is  shown  in  Figure  5 1 . 
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Figure  5 1 .  Contour  Plot  for  Focal  Length  vs.  Pixel  Pitch 


By  looking  at  Figure  5 1,  it  can  be  seen  that  the  optimal  value  for  the  two  variables 
when  interacting  shifts  a  little  from  the  values  derived  earlier.  The  Optimal  point  is 
shown  in  the  lower  right  quadrant,  with  focal  length  around  0.9  and  pixel  pitch  at 
4.2  *  10_7m. 

As  can  be  seen  by  the  previous  simulations,  finding  the  optimal  parameters  to 
design  the  nadir  portion  of  the  SSA  system  takes  some  concentrated  analysis.  Since  the 
values  found  are  not  consistent,  they  can  be  further  refined  using  the  Sequence 
Optimization  Tool  (SEQOPT),  also  known  as  the  Design  Explorer  Surrogate 
Optimization  Tool. 

SEQOPT  is  used  to  intelligently  optimize  surrogate  models  to  accelerate  the 
optimization  process.  However,  in  order  to  use  SEQOPT,  starting  points  are  required,  so 
the  previously  derived  values  will  be  used.  The  SEQOPT  algorithm  will  be  used  to 
systematically  modify  variables  in  a  Scenario  until  some  objective  is  met.  In  this  case,  the 
objective  was  optimizing  pixel  pitch  and  focal  length  while  holding  semi-major  axis  and 
inclination  at  a  fixed  position.  The  setup  of  this  tool  can  be  seen  in  Figure  52. 
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Figure  52.  Setup  of  Design  Explorer  Surrogate  Optimization  Tool 


Once  the  scenario  is  run,  the  output  from  the  SEQOPT  tool  detennined  the 
following  optimal  values  for  the  listed  parameters. 

•  Focal  Length:  2.0  *  10_1m 

•  Detector  Pitch:  1.018  *  10_7m 

•  Cone  Angle:  49.28° 

The  output  for  these  results  can  be  seen  in  Figure  53  and  Figure  54.  Figure  53  shows  the 
focal  length  vs.  run  number  and  Figure  54  shows  the  final  report.  For  the  purposes  of  this 
thesis,  the  values  given  above  will  be  the  final  values  used  to  design  the  nadir  sensor. 
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Figure  53.  SEQOPT  Tool  Output  1 


Figure  54.  SEQOPT  Tool  Output  2 


Now  that  the  nadir  sensor  parameters  have  been  specified,  the  next  step  is  to 
determine  the  optimal  parameters  for  the  forward  and  aft  facing  sensors.  To  do  this,  the 
Electro-optical  and  Infrared  (EOIR)  toolkit  will  be  used  to  analyze  the  SSA  functions  of 
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the  sensors.  Specifically,  the  EOIR  will  be  used  to  determine  what  the  signal-to-noise 
ratio  (SNR)  should  be  for  the  notional  lm  sized  targets.  The  SNR  dictates  how  the  sensor 
discriminates  a  desired  signal,  in  this  case  the  target,  from  the  background  noise,  in  this 
case  other  objects  in  space  (e.g.,  stars,  planets)  (Wertz  and  Larson  1991,  243).  Once  this 
portion  of  the  analysis  is  completed,  the  number  of  satellites  to  provide  SSA  in  an  entire 
plane  can  be  derived. 

The  first  step  for  this  portion  is  to  create  two  sensors  on  the  spacecraft  using  the 
toolkit.  The  toolkit  allows  the  properties  of  the  sensors  to  be  defined,  as  shown  in  the  next 
several  figures.  The  first  step  is  to  select  the  EOIR  Sensor  Plug-in  as  shown  in  Figure  55. 
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Figure  55.  Select  EOIR  Sensor  Plug-In 


Once  the  EOIR  Sensor  Plug-in  is  launched,  the  properties  of  the  sensor  can  be 
populated.  In  the  Spatial  tab  for  the  sensors,  a  10°  Horizontal  by  10°  Vertical  field  of 
view  was  chosen  as  a  notional  sensor  field  of  view.  This  is  shown  in  Figure  56.  The 
remaining  values  in  the  properties  were  default  values  used  from  STK  and  are 
shown  in  Figure  57  through  Figure  59. 
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Figure  56.  Sensor  Properties  #  1 
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Figure  57.  Sensor  Properties  #  2 
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Figure  58.  Sensor  Properties  #  3 


87 


EOIR  Properties  Sensorl 


Render  Edit  Band 

®  Band 


Add...  Save  Configuration . . 


Spatial  |  Spectral  Optical  Radiometric 
Units  for  Saturation  and  Sensitivity 

0  Ir radiance  (W/cm2) 

%  Radiance  (W/(cm2  sr)) 

Sensitivity 

Reference  Noise  Equivalent 
Irradiance  (NEI)  vs.  Integration 
Fine  Pairs 


Edit.. 


Dynamic  Range 

Upper  End  of  Dynamic  Range 
0  Unlimited  (no  saturation) 
Simulate  Saturation 

Reference  Saturation  Equivalent 
Irradiance  (SEI)  vs.  Integration 
Time  Pairs 


Edit... 


Integration  Time  (msec) 

NEI  (W/cm2) 

100.0000 

1.000e-015 

Integration  Time  (msec) 

SEI  (W/cm2) 

100.0000 

3.000e-012 

Current  Integration  Time,  Sensitivity,  and  Dynamic  Range 
Integration  Time:  1000.0000  (msec) 


Dynamic  Range:  940.6833 


NO:  3.162e-016  (W/cm2) 

SEI:  3.000e-013  (W/cm2) 


Processing  Level:  Geometric  Input 


OK 


Line  of  Sight  Jitter:  0.0000 

Apply 


(mrad) 


Cancel 


Help 


Figure  59.  Sensor  Properties  #  4 


Once  the  sensor  properties  are  filled  in,  the  Ok  button  can  be  pressed  and  the 


sensors  are  created. 


88 


The  created  sensors  fields  of  view  are  shown  in  Figure  60  as  the  two  bluish  cones 
along  the  orbital  path. 


Figure  60.  Forward  and  Aft  SSA  Sensors 


After  the  sensors  have  been  created,  the  next  step  is  to  create  a  target  for  the 
sensors  to  find.  In  this  case,  a  1-meter  lambertian  sphere  (i.e.,  a  sphere  that  is  uniformly 
specularly  diffuse  or  reflects  light  evenly)  is  created.  In  addition,  20%  reflectance  is 
specified  for  the  target  and  grey  body  material  is  selected  as  a  representative  piece  of 
space  debris.  Finally,  the  temperature  of  the  object  is  specified  as  273  Kelvin,  or 
0°Celsius.  This  target  is  a  notional  piece  of  space  debris  since  it  would  be  near 
impossible  to  simulate  every  type  of  debris  that  could  be  encountered  by  an  SSA  sensor. 
However,  the  object  should  provide  a  sufficient  simulation  to  develop  parameters  for  the 
sensor.  The  setup  for  the  target  is  shown  in  Figure  61. 
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After  the  debris  parameters  have  been  specified,  the  orbit  for  the  debris  must  also 
be  specified.  In  this  case,  two  objects  are  placed  in  the  same  orbital  plane  as  our  notional 
LEO  hosted  SSA  payload  30°  away  in  each  direction.  A  visual  representation  of  the 
debris  in  the  orbital  path  is  shown  in  Figure  62.  They  are  labeled  EOl  and  E02  in  green 
lettering. 
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Figure  62.  Space  Debris  in  Orbital  Plane 

In  the  window  to  the  right  of  the  Earth  in  Figure  62  is  a  view  of  what  the  SSA 
sensor  sees.  To  the  casual  and  expert  observer,  it  looks  like  a  field  of  stars;  however,  one 
of  the  miniscule  white  dots  in  the  field  is  actually  the  piece  of  debris  created.  While 
looking  at  the  field  of  view  does  not  allow  debris  to  be  differentiated  from  the  stars, 
looking  at  the  SNR  does.  The  sensor,  as  it’s  orbiting,  will  compare  the  SNR  of  each  of 
the  objects  to  see  what  changes.  If  the  object  is  a  star,  then  the  SNR  will  remain  constant 
since  the  star  is  far  away.  However,  if  the  speck  in  the  field  of  view  is  a  piece  of  debris, 
the  SNR  theoretically  should  change  as  the  object  gets  closer  or  further  away  from  the 
sensor.  The  objective  and  threshold  values  for  SNR  are  not  defined  since  a  TRD  was  not 
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developed,  so  for  the  purposes  of  this  simulation,  a  notional  SNR  greater  than  2.0  will  be 
considered  sufficient. 

To  show  how  a  piece  of  space  debris  or  an  object  looks  as  it  is  moving  through 
the  sensor’s  view,  the  following  three  figures  are  provided  with  the  debris  circled  in  red 
in  each  one.  The  reader  should  take  notice  of  the  cluster  of  two  stars  in  the  yellow  square 
and  how  they  move  in  relation  to  the  debris. 
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Figure  64.  Sensor  Debris  and  Star  View  #  2 
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Now  that  the  reader  understands  how  the  object  appears  to  the  sensor,  the  next  step 
was  to  run  the  simulation  to  discover  what  the  SNR  is  for  the  objects  30°  away.  This  is 
accomplished  by  generating  the  sensor-to-target  metric  report  in  the  EOIR  toolkit  as 
shown  in  Figure  66. 


Figure  66.  EOIR  Sensor-to-Target  Metric  Report  Generation 
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Once  the  Generate  option  is  selected,  STK  steps  through  a  60-minute  simulation 
to  show  the  changing  SNR  of  the  space  debris  in  the  orbital  path.  The  results  are  shown 
in  Figure  67. 
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Figure  67.  SNR  for  Space  Debris  30°  Away 


As  can  be  seen  from  the  report,  the  SNR  is  around  5.4  at  the  point  the  object  is 
closest  to  the  sensor.  As  the  object  drifts  further  away  from  the  sensor,  the  SNR  decreases 
to  around  3.2.  For  the  purposes  of  this  thesis,  this  means  the  SNR  has  exceeded  the  goal 
of  2.0,  and  the  sensor  parameters  can  be  considered  sufficient  for  use  as  hosted  SSA 
sensors. 
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Now  that  the  optimal  orbit  and  sensor  parameters  for  the  nadir,  forward  and  aft 
sensors  have  been  determined,  the  final  step  is  to  replicate  the  single  satellite  multiple 
times  to  provide  coverage  for  an  entire  orbital  plane.  This  is  done  using  a  simple  copy 
and  paste  function  in  STK  to  replicate  the  LEO  satellite  and  spacing  them  evenly  around 
the  globe.  The  results  can  be  seen  in  Figure  68  and  Figure  69. 


Figure  68.  Single  Plane  Hosted  SSA  Payload  Constellation 
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Figure  69.  Single  Plane  Hosted  SSA  Payload  Constellation  with  GEO  Relay  and 

Downlink  to  Monterey,  CA 


What  can  be  seen  from  the  final  images  is  that  six  satellites  are  required  to 
provide  worldwide  SSA  using  hosted  payloads  in  a  single  plane.  It  should  be  noted  that 
this  constellation  has  been  optimized  to  provide  maximum  coverage  of  the  Earth  from  the 
nadir  facing  sensors  as  well. 

C.  ARCHITECTURE  CONCLUSIONS 

After  the  requirements  and  the  simulations  were  completed,  the  final  step  for 
developing  the  architecture  was  to  develop  an  Operational  View  (OV)  for  the  proposed 
system.  An  OV  is  one  of  the  basic  views  in  the  Department  of  Defense  Architecture 
Framework  (DoDAF).  The  OV-1  is  the  high-level  graphical  and  textual  description  of  the 
operational  concept.  This  View  will  provide  a  means  to  visualize  and  understand  the 
broad  scope  and  complexities  of  the  architecture  being  proposed.  In  particular,  the 
Operational  View  will  detail  the  complex  operating  domain  in  which  the  final  system  will 
operate  (DoD  Deputy  Chief  Information  Officer  2011,  139).  Figure  70  shows  the 
proposed  OV-1. 
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Figure  70.  Proposed  Operational  View 


To  better  understand  the  OV,  the  OV  should  be  looked  at  from  left  to  right.  In  the 
bottom  left  comer,  the  proposed  constellation  from  the  STK  simulations  is  shown 
orbiting  the  Earth.  On  the  Earth  are  several  threats,  SOSI  tracking  stations,  laser  threats 
and  ground  based  anti-satellite  weapons.  A  single  satellite  from  the  constellation  is 
portrayed  in  more  detail  encountering  several  threats.  The  three  ground-based  threats 
described  earlier  as  well  as  natural  environmental  threats,  such  as  meteorites,  and  co¬ 
orbital  anti- satellite  weapons  are  also  introduced.  From  this  single  satellite,  a 
representative  hosted  payload  is  shown  relaying  threat  information  from  the  sensors  over 
varying  communication  methods.  The  communication  methods  shown  include  a  relay 
satellite,  shown  as  a  connection  with  yellow  lines,  as  well  as  direct  communication  from 
the  payload  to  the  ground,  shown  by  the  red  line.  Additionally,  another  hosted  SSA 
system  on  a  satellite  is  shown  in  the  upper  right  hand  corner.  This  system  depicts 
information  being  sent  over  the  host  spacecraft  communication  link.  Finally,  once  the 
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data  has  arrived  to  the  ground  station,  represented  by  the  satellite  dish  receiving  the 
communication  signals,  the  data  can  be  passed  over  the  global  infonnation  grid  (GIG)  to 
the  JSpOC  or  space  operations  center  (SOC). 

The  infonnation  passed  to  the  SOC  is  what  was  called  “local”  SSA  at  the 
beginning  of  this  thesis.  The  local  SSA  would  be  provided  to  the  user  of  the  particular 
satellite  and  could  be  used  to  better  understand  what  is  happing  to  the  particular 
spacecraft.  In  addition,  by  utilizing  the  information  form  the  hosted  payloads  and  sending 
the  information  into  the  JSpOC,  the  data  can  be  fused  together  to  begin  providing 
“global”  SSA. 
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V.  CONCLUSIONS 


A.  RESEARCH  SUMMARY 

Currently  the  U.S.  relies  on  primarily  on  ground-based  radars  and  one  space  based 
system  to  provide  SSA.  However,  there  are  other  means  to  provide  SSA  the  U.S.  should 
use.  Satellites  are  launched  on  a  regular  basis  for  defense,  scientific  and  commercial 
purposes.  These  satellites  all  hold  the  potential  to  contribute  to  the  worldwide  SSA 
picture  by  utilizing  hosted  SSA  payloads  on  board.  These  unconventional  payloads 
provide  the  flexibility  in  cost  and  performance  that  cannot  be  achieved  by  conventional 
SSA  systems.  In  addition,  hosted  payloads  paired  with  the  correct  instruments  provide  a 
capability  that  does  not  currently  exist  with  ground-based  radars.  This  capability  is 
“local”  SSA,  a  means  for  a  satellite  and  its  operator  to  know  what  is  in  a  spacecraft’s 
immediate  vicinity.  Additionally,  if  the  data  from  hosted  payloads  is  properly  fused  and 
analyzed,  the  capability  to  develop  a  worldwide  SSA  picture  (i.e.  “global”  SSA)  exists. 

To  understand  what  would  be  required  to  develop  a  SSA  architecture  utilizing 
hosted  payloads,  two  research  questions  were  asked: 

1)  What  are  the  requirements  for  an  individual  satellite  to  provide  local 
SSA  using  a  hosted  payload? 

2)  How  should  individual  SSA  payloads  be  distributed  to  provide  a 
worldwide  SSA  picture?  In  other  words,  what  should  the  architecture 
look  like? 

By  examining  these  two  questions,  this  researcher  set  out  to  understand  how  to  provide 
SSA  using  hosted  payloads. 

To  answer  the  first  question,  multiple  programs  were  studied  to  gain  a  better 

understanding  on  what  type  of  requirements  would  make  for  a  successful  hosted  SSA 

payload.  Ultimately,  nine  generic  high-level  requirements  were  developed  to  build  a 

hosted  SSA  payload.  These  nine  requirements  were  the  answer  to  the  first  question. 

These  requirements  provide  a  means  to  develop  the  underpinnings  of  a  SSA  architecture 

based  on  hosted  payloads.  Having  a  hosted  SSA  payload  that  is  adaptable  to  multiple 
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scenarios  and  can  accommodate  various  sensors  is  the  best  means  for  providing  SSA  via 
hosted  payloads  on  multiple  satellites. 

The  second  research  question  in  this  thesis  was  answered  by  perfonning  physics 
based  analysis  using  STK.  The  purpose  of  the  analysis  was  to  design  a  notional  system  in 
a  single  plane  that  maximized  SSA  using  the  hosted  payloads.  Due  to  the  academic 
nature  of  the  analysis,  the  analysis  was  bounded  to  a  single  plane.  The  optimal  orbit  was 
found  which  would  maximize  SSA,  and  three  notional  sensors  were  designed  to  support 
“local”  SSA.  At  the  conclusion  of  the  STK  simulations,  it  was  found  that  six  satellites 
with  hosted  SSA  payloads  could  provide  a  worldwide  SSA  picture  in  a  single  plane. 

Using  the  requirements  and  the  STK  simulations  as  a  basis,  an  OV-1  was 
developed  as  the  final  architecture  product  for  this  thesis.  The  OV-1  provides  a  notional 
depiction  of  the  architecture  for  “local”  and  “global”  SSA.  By  fielding  the  hosted  SSA 
payloads  around  an  orbital  plane  and  distributing  the  threat  data  to  satellite  operations 
centers  as  well  as  the  Joint  Space  Operations  Center,  “local”  and  “global”  SSA  can  be 
achieved. 

B.  AREAS  FOR  FURTHER  RESEARCH 

Since  this  thesis  was  limited  in  depth  and  breadth  due  to  the  academic  nature  of 
the  work,  there  are  areas  for  further  research.  The  requirements  analysis  was  limited  to 
high-level  requirements  since  information  required  to  develop  a  TRD  was  not  available  in 
the  academic  setting.  One  area  for  additional  work  is  to  develop  a  TRD,  which  further 
defines  the  hosted  SSA  payload  requirements.  Additionally,  some  requirements  may 
require  technology  that  is  above  the  unclassified  level.  Any  further  requirements 
development  should  be  done  at  the  appropriate  classification  level  to  ensure  appropriate 
security  is  maintained. 

For  this  thesis,  limited  analysis  was  performed  at  a  high  level.  If  this  system  were 
actually  to  be  built,  further  analysis,  such  as  more  detailed  functional  analysis,  function  to 
physical  mapping  and  environmental  analysis  would  need  to  be  performed  as  well.  Also  a 
reliability  analysis  could  also  be  conducted  to  determine  how  well  the  system  would 
perform  over  time. 
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The  analysis  that  was  conducted  with  respect  to  sensor  development  was  done 
with  notional  values.  An  area  for  further  research  would  be  to  use  realistic  values  from 
sensors  developed  by  the  defense  industry  and  rerun  the  simulations.  The  analysis  may 
reveal  that  additional  satellites  are  required  to  provide  worldwide  coverage. 

Another  area  for  further  research  is  with  respect  to  the  field  of  views  of  the 
sensors.  The  sensors  modeled  in  this  thesis  only  provided  SSA  in  the  nadir,  forward  and 
aft  directions  of  the  satellite.  Further  modeling  could  be  done  with  a  sensor  that  provides 
four-pi  steradian  coverage  (i.e.,  a  360°  sphere  around  the  satellite). 

Finally,  the  research  conducted  in  this  thesis  was  limited  to  a  single  plane  to 
ensure  computational  times  for  simulations  were  kept  to  reasonable  amounts.  To  truly 
develop  a  sense  for  how  many  satellites  would  be  required  to  provide  coverage  in  all 
orbital  planes,  further  simulations  should  be  conducted.  In  addition,  the  simulations 
conducted  should  be  expended  from  LEO  to  MEO  and  GEO  satellites  as  well. 
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